Bash tool results silently lost — agent waits forever (no timeout fires); correlates with Remote Control sessions

Summary

Since ~v2.1.167, Bash tool calls (in both the main loop and subagents) intermittently never return a result. The command itself completes — there are no orphaned zsh -c processes — but the harness never delivers the tool_result, so the session/subagent waits indefinitely with no error, no timeout, and no progress indication. The only recovery is manually pressing ESC and asking Claude to retry. When the failure is visible at all, it surfaces as:

[Tool result missing due to internal error]

This is severe in multi-subagent workflows (plan/review pipelines): a subagent hangs silently and the parent shows no activity for 30 minutes to 2+ hours until manually interrupted.

Environment

• macOS (Darwin 25.6.0, Apple Silicon), zsh, Warp terminal
• Claude Code v2.1.167–v2.1.172 (reproduced on .167, .168, .170, .172)
• v2.1.143 (May 30) was clean: 96 Bash calls in a Remote Control session, zero incidents
• BASH_DEFAULT_TIMEOUT_MS=120000, BASH_MAX_TIMEOUT_MS=600000 set in settings — never fires for this failure mode
• remoteControlAtStartup: true (Remote Control bridge active in affected sessions)

Evidence (from transcript analysis across ~30 sessions, June 6–10 2026)

Scanned all project transcripts for Bash tool_use blocks and their matching tool_result:

• 8 calls never received a result (transcript simply ends/moves on after the tool_use). The commands were trivial and non-interactive: ls <dir>, sed -n '1,120p' file, mkdir -p, node -e '...', cp && node script.mjs.
• ~15 calls returned after 150s–4987s wall-clock for commands that should take milliseconds (e.g. sed of one file: 433s, 623s; echo + grep: 4987s). Machine was awake the whole time (verified against pmset -g log).
• Default 120s timeout never triggered on any of these — consistent with the child process having already exited and the result being lost in delivery, rather than a hung command.
• No orphaned shell processes exist after the hangs (ps shows nothing matching the hung commands).
• When a parallel tool batch hangs, none of the parallel calls' results get logged (e.g. one Bash + two Reads issued together: all three missing).

Correlation with Remote Control

• Every session containing hangs had bridge-session events (Remote Control active). The heaviest session (161 bridge events, large parallel-subagent fan-out) had 6 never-returned + 13 slow calls.
• ~20 recent sessions without bridge activity: zero hangs.
• In the most recent session, both failures ([Tool result missing due to internal error]) coincided exactly with a user message arriving mid-tool-call (sent while tools were executing).
• A v2.1.143 session with Remote Control active was clean → looks like a regression after 2.1.143, present by 2.1.167.

Ruled out

• Command content — trivial read-only commands hang; nothing interactive, no stdin reads, no daemons.
• macOS sleep — hangs occurred during fully-awake periods per pmset -g log (one full workday had a single 49s sleep; five hangs that day).
• Shell snapshot / terminal integration — snapshot contains no Warp/network hooks (only PATH).
• User timeout config — BASH_DEFAULT_TIMEOUT_MS was set the whole time.

Expected behavior

If a tool result cannot be delivered, the harness should return an error result (so the model can retry) rather than waiting indefinitely; at minimum the configured Bash timeout should bound the wait.

Impact

Multi-hour silent stalls in agentic sessions; requires manual ESC + "retry" each time.