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).
2. 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.
2. 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.