Background shell tasks return empty logs; provider errors (too_many_images, timeouts) and subagent failures stall long coding sessions

run_in_background=true を指定した shell_command の CLI エントリポイントから始め、Gradle と PowerShell のケースを再現し、取得した出力を daemon ログおよび終了ステータスと比較します。次に、provider の image-budget エラーとサブエージェントのエラー処理を追跡し、利用可能な場合は記載された trace IDs を使用します。バックグラウンドの失敗でステータスと stderr が公開され、provider の制限が処理され、エラーになったサブエージェントが部分レポートを保持すれば完了です。

Long coding session crippled by tooling failures: empty background-task output, provider errors, lost subagent reports

Environment

• Windows 11, Command Code CLI (npm, v1.39.x line at the time)
• Large Android/Gradle project; long-running builds (1–5 min per gradle invocation)
• One long single-session refactor task (~15 files edited + verification builds + CI screenshot step)

Summary

A large but well-scoped coding task stretched for hours almost entirely because of harness/infra failures, not task complexity. Four classes of failure, each reproducible within the session:

1. Background shell commands return empty output logs (most damaging)

• shell_command with run_in_background=true running gradlew ... > file.log 2>&1 or piped through | powershell ... produced 0-byte output logs for 20–60+ minutes while gradle had actually failed in 40 seconds.
• Exit status was never surfaced; the log stayed empty; the only way to learn the real failure was to manually read ~/.gradle/daemon/9.5.0/daemon-*.out.log (the daemon's own log contained e: file:///...kt:NN Unresolved reference... compile errors all along).
• Piping task output through PowerShell (| powershell -Command "$input | Select-Object -Last N") also silently lost everything.
• Cost: this failure mode alone consumed the majority of the session, with multiple redundant 5–10-minute polling loops staring at empty files.
• Expected: background tasks should surface real exit codes/stderr (or at minimum, the streamed log should contain the process's output as it appears).

2. Repeated mid-session provider errors, each requiring a manual "continue"

• Error: 200 Failed to process successful response
• Error: 500 Cannot connect to API: Connect Timeout Error (172.65.90.20-23:443)
• Error: 400 Invalid_request_error ... [too_many_images] GLM requests accept at most 8 inline PNG/JPEG/WEBP/GIF ... — a session that reviews screenshots (dev workflow!) becomes unsendable until the user manually compacts. The model can't fix this itself.

3. Subagent runs errored and lost their reports

• One general subagent returned [sub-agent stopped early: the run errored] after 20 minutes, mid-task (had made real edits already).
• A separate audit subagent died entirely with its report lost; had to be relaunched from scratch.
• Expected: partial output preserved on subagent error, or automatic retry.

4. Tool-schema friction

• search_tools repeatedly returned todo_write schema, but calling it kept failing/looping for several turns before it finally worked.

Trace IDs (from the error banners in one session)

• 6b481a97ce2ad552cb4802dc72d0b0ef
• 39a179d53c81ee36fea47ff7f116d066
• 52c2bcc5f22d1a3815bb7b6a4ce81356
• ca6c03357b892c7ca6e9042e6ecb6367
• 2cc56255ce5d8e9aab41e69325ec4e81

Ask

1. Surface real exit status + stderr of background and piped shell tasks; don't let empty logs masquerade as "still running."
2. Handle the image budget proactively (auto-compact or drop stale images before the provider hard-fails the whole conversation).
3. Preserve subagent partial reports when a run errors.