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

Commencez par les points d’entrée de la CLI pour shell_command avec run_in_background=true et reproduisez les cas Gradle et PowerShell, en comparant la sortie capturée avec le journal du daemon et le statut de sortie. Suivez ensuite les erreurs de budget d’images du fournisseur et la gestion des erreurs des sous-agents, en utilisant les trace IDs indiqués lorsqu’ils sont disponibles. C’est terminé lorsque les échecs en arrière-plan exposent le statut et stderr, que les limites du fournisseur sont gérées et que les sous-agents en erreur préservent les rapports partiels.

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.