[Bug] Parallel tool batch cancels all remaining calls when one call fails

Bug Description

Claude Code — session reliability feedback

Paste into /bug (or trim to taste). Written 2026-05-30. Two items: one confirmed
behaviour, one unconfirmed symptom — labelled honestly.

---

1. (Confirmed) One failed call in a parallel tool batch cancels the whole batch

What happened: Across a long coding session I frequently sent multiple tool calls
in a single assistant turn (reads + edits + bash, sometimes 10–20 at once). Repeatedly,
a single non-fatal failure in the batch caused every other call in that batch to be
cancelled with Cancelled: parallel tool call <X> errored. Examples of the triggering
"failure":

• pkill -f "journalctl …" returning a non-zero exit (nothing to kill) — exit 144.
• A curl probe hitting an expected 404.
• A python3 - <<'PY' heredoc raising on a missing file.

In each case ~10–25 unrelated, independent edits/reads in the same batch were thrown
away. Because some of those were Edit/Write calls, work I believed had landed
silently had not — forcing repeated re-verification and re-application of the same edits.

Why it's a problem: batches mix independent operations. A trivial expected non-zero
exit (very common with pkill, grep -c, curl probes) shouldn't nuke 15 unrelated
file edits. It turns a 1-line failure into a multi-minute recovery and creates a real
risk of partially-applied changes.

Suggested fix: make tool calls in a batch independent — a failure in one returns
its own error but lets the others run to completion (fail-soft per call), rather than
cancelling the remainder. If cancel-on-error must stay, surface it far more loudly
(a summary like "12 of 15 calls cancelled because call #3 errored").

Workaround I adopted: stop batching dependent/heterogeneous calls; issue small
sequential calls. This eliminated the cancellations entirely — confirming the cause.

2. (Unconfirmed) Possible garbling of multi-line tool output

Symptom: intermittently, Read results and multi-line bash output appeared to
contain duplicated lines, stray/garbled characters, or content that didn't match the
file (e.g. a git diff rendering with lines that the file did not contain). Re-running
the same read, or reducing it to a single-line machine-countable form (grep -c,
ast.parse, AST element counts), consistently returned correct results.

Caveat — I cannot confirm this is a real harness fault. It may have been a genuine
display/transport glitch, or it may have been me misreading otherwise-correct output.
I could not reproduce it deterministically. Flagging it only as "observed, unconfirmed"
in case it correlates with anything on the backend (e.g. interaction with very large
files — the affected file was ~3,600 lines).

Mitigation that worked: verifying every edit via ast.parse + integer/grep counts
instead of trusting raw multi-line reads. The final code state was verified correct by
those means despite the noisy reads.

---

Environment: Claude Code CLI, Linux Mint 22.3, working in a ~3.6k-line Python file.
Net effect: the work completed correctly, but took substantially longer than it should
have, mostly due to item #1 (which is on me for batching, but the cancel-all semantics
made the cost disproportionate).

Environment Info

• Platform: linux
• Terminal: vte-based
• Version: 2.1.158
• Feedback ID: 1b030e00-12b7-46c4-944a-68dee72bada3

Errors

[{"error":"Error: Native image processor module not available\n    at q (/$bunfs/root/src/entrypoints/cli.js:625:2741)\n    at metadata (/$bunfs/root/src/entrypoints/cli.js:625:2890)\n    at BjH (/$bunfs/root/src/entrypoints/cli.js:665:5214)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-30T15:22:16.083Z"}]