[Bug] Parallel tool calls hang on Bash execution errors

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/63576
2. https://github.com/anthropics/claude-code/issues/22264
3. https://github.com/anthropics/claude-code/issues/63192

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

observed on linux x86, claude-code v2.1.158

It's all over my sessions on macos. Basically harness is broken and often model confuses harness refusals with user "stop" messages. Just like other issues with CC - this one will drown in the sea of duplicates and all will be closed for inactivity by the bot in a few weeks. The actual bug will get fixed when OpenAI releases earnings for Q2 showing how it's smashing CC with Codex and then the team will have a meeting to see what's wrong, they'll understand harness is broken and will fix it in 15 mins after.

Let's see how this plays out :)

Reproduced on Linux x86, claude-code v2.1.158, claude-opus-4-8, three separate sessions over three days (2026-05-29 to 2026-05-30). In each case a single Bash call returning non-zero in a parallel batch cascade-cancelled all sibling calls with the same Cancelled: parallel tool call Bash(...) errored line, sometimes 5–10 deep.

Switching the same workspace to claude-opus-4-7 on the same CLI version (2.1.158) — no other changes — eliminates the cascade entirely. Confirmed with a 4-test probe (parallel-cancel / stdout-truncation / cwd-reset / result-consistency): 4/4 fail on 4.8, 4/4 pass on 4.7. So the trigger is model-side, not CLI-side; CLI downgrade to 2.1.157 did not help.

Related and likely the same root cause: #22264 (sibling-cancel mechanic), #55515 (grep exit 1 triggers it), #63192 (cancel corrupts thinking blocks → 400 wedges session), #63364 (full softbrick example).

Workaround that holds: stay on 4.7, or set CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY=1 on 4.8 to remove parallel batches entirely (sequential, slower, but no cascade possible).

@hungduong-projects, @chanmaoganda, @maxpavlov, @jbruder — adding cluster context that has come together across independent reports between 2026-05-30 and 2026-05-31, in case it helps triage and other operators hitting the same loop:

Cluster shape (5 reports in 48 hours, ~50 cumulative reactions across the set)

| Anchor | When | Filer's shape |
|---|---|---|
| #64047 | 2026-05-30 | 25-call cascade leading to 2-hour model fabrication of user-interrupt state with zero actual user input (load-bearing first-person transcript from @snichols) |
| #64052 | 2026-05-30 | v2.1.158 / darwin / ghostty minimal repro, single cd Bash error (@omar16100) |
| #64059 | 2026-05-30 | 10-20-call batches across long coding sessions, multiple non-fatal triggers (@enrico2468) |
| #64080 | 2026-05-31 | Within-turn re-emission: 18 dispatches with zero interleaved results (@SynVisions) |
| #63881 (this) | 2026-05-30 | Bash error cascade, v2.1.158 / darwin / vscode + Linux x86 reproductions |

The duplicate bot list at the top of this issue (#63576, #22264, #63192) confirms the same fingerprint has surfaced repeatedly across the codebase. The aggregate cost is invisible from inside any single thread's reaction count, which is why the bot keeps proposing dup-close — the structural shape is real but the per-issue engagement reads as low-priority.

Four structurally distinct axes

• 20A — Cascade behavior: the batch cancellation policy is "fan-out, abort on first failure"; the right semantic for parallel reads/probes is "fan-out, continue on partial failure." Any single non-fatal exit (Bash 1, pkill exit 144 with nothing to kill, curl 404, git invalid revision exit 128) cancels every sibling in the same batch.
• 20B — Cancellation message indistinguishability: Cancelled: parallel tool call X errored reads identically to a user interrupt; the model itself misattributes the cascade and fabricates user statements ("You're right to stop me…") that never happened. This is the load-bearing failure mode behind the multi-hour fabrication in #64047.
• 20C — Self-aware drift after misread: after the misattribution from 20B, the model recognizes mid-session that "something is very wrong," composes handoff documents acknowledging the divergence, and still does not stop the loop. Detection canary: grep -l "handoff" ~/.claude/projects/*/recent.jsonl — handoff-shaped output is rare in healthy sessions, so a positive count is a strong Axis-3 signal.
• 20D — Within-turn re-emission: model degenerates inside one turn and re-emits an identical parallel tool_use batch K times before yielding. Reasoning-cost backstop has to live at the token-stream layer, before the parallel tool_use blocks finish emitting — execution-layer dedup saves execution cost but not reasoning cost.

Three operator-side mitigations (works today, while upstream fix is unknown)

1. Cap parallel batch size at N=3–5 via CLAUDE.md guidance until the policy changes. The cascade still happens but contains fewer wasted reasoning tokens per fire.
2. Audit transcripts with grep -c "parallel tool call.*errored" ~/.claude/projects/*/recent.jsonl to surface how often you've hit the cascade silently.
3. Avoid Bash / curl / pkill / git in parallel batches when failure-on-empty is common (the four most-cited triggers across the cluster reports). Keep these sequential; parallelize file reads and pure probes only.

Two automatic detection hooks (MIT, no paid product, no sign-up):

• parallel-cascade-detector.sh — PostToolUse reactive, rolling-window counting with configurable threshold; surfaces volume signal after cascade. Source: examples/parallel-cascade-detector.sh in the cc-safe-setup repo.
• parallel-batch-size-limiter.sh — PreToolUse proactive, 500ms rolling batch window with debounce; surfaces batch size before any failure can cascade. Source: examples/parallel-batch-size-limiter.sh in the same repo.

Both addressed in this morning's cluster-tracker update at https://yurukusa.github.io/cc-safe-setup/cluster-tracker.html#cluster-20 (search for "Cluster 20 candidate").

@maxpavlov's "drown in the sea of duplicates and all will be closed for inactivity" observation is structurally correct for this issue class — that's exactly why a cross-thread cluster framing helps. Cross-linking @hungduong-projects's report into the #64047 / #64080 articulation so the cluster doesn't fragment further.