Parallel tool-call batch cascades "Cancelled" to independent calls when one fails

Issue draft: Parallel tool-call batch cascades "Cancelled" to independent calls when one fails

提出先想定: https://github.com/anthropics/claude-code/issues 提出はユーザーが行う（このドラフトは Claude が外部送信していない）

Summary

When Claude issues multiple tool calls in a single assistant turn (parallel batch),
a failure (non-zero exit) in one call causes all other calls in the same
batch to be returned as Cancelled — even when those other calls are completely
independent (e.g. git status, Read, unrelated Bash). The independent work is
discarded and must be re-issued, which wastes a full round-trip and amplifies
confusion in long sessions.

Environment

• Claude Code (CLI), model: claude-opus-4-8
• Platform: Linux 6.8.0 / bash
• Long-running session with frequent multi-tool batches

Steps to reproduce

1. In one assistant turn, issue ~10 independent tool calls in parallel, where one

of them is a Bash command that exits non-zero (e.g. a psql query that hits a
wrong column name → exit 3).

1. Observe the results.

Expected

Independent tool calls that already ran (or could run) should return their own
results. Only the failing call should report its error.

Actual

The failing call returns its error; every other call in the batch returns
Cancelled: parallel tool call Bash(...) errored, including read-only commands
(git status, git diff, Read) that had no dependency on the failed call.

Observed twice in a single session. Example: a psql call failed with
ERROR: column "project" does not exist, and 13 unrelated calls in the same batch
were all cancelled.

Impact

• Forces re-execution of independent work → extra latency and token cost.
• In long sessions it compounds with two other rough edges (below), making the

agent appear to "error repeatedly" when the root failure was a single call.

Secondary observations (lower confidence, possibly related/flaky)

1. Empty tool output: occasionally a Bash command that should print output

returns (Bash completed with no output); re-running the identical command as a
single call returns the expected output. Seen for git rev-parse/echo during
high-throughput turns.

1. Output association in long sessions: when many parallel results stream back,

it is easy to mis-associate which result belongs to which call (git hash /
verdict mix-ups). Single-call re-fetch resolves it. A clearer per-call result
binding in the UI would help.

Suggested direction

• Do not cascade-cancel independent calls in a parallel batch on a single call's

failure; return each call's own result/error.

• (Optional) Surface a clear "N of M calls in this batch failed" rather than

blanket-cancelling the rest.

Note on scope

A portion of the errors in the originating session were the model's own (batching
dependent steps, guessing a DB column name instead of reading the live schema
first). Those are not platform bugs. This report is scoped only to the
cascade-cancel behavior and the two secondary observations above, which are
harness-side and not fully avoidable by prompting discipline.