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"}]