Sibling tool call errored: parallel tool calls cascade-fail when one fails

[ilanoh]

Description

When Claude Code makes multiple tool calls in parallel (in a single message) and one of them fails, all remaining sibling calls in that batch are automatically cancelled with the error:

Error: Sibling tool call errored

This forces a retry of all the cancelled calls individually, adding unnecessary round-trips and context usage.

Steps to Reproduce

1. Claude sends a single message with multiple parallel Edit tool calls (e.g., 5 edits across different files)
2. One edit fails (e.g., old_string not found due to a prior edit changing the file)
3. All other edit calls in the same batch — even those targeting completely different files — are cancelled with Sibling tool call errored

Expected Behavior

Independent tool calls that target different files should succeed or fail independently. A failure in one Edit call to file_a.js should not cancel an Edit call to file_b.js.

Actual Behavior

All sibling tool calls are cancelled regardless of whether they would have succeeded. Claude then has to re-read files and retry each call individually.

Impact

• Extra round-trips and increased latency
• Wasted context window (re-reading files, retrying edits)
• Higher token usage / cost for users
• Particularly noticeable when making broad changes across many files (e.g., adding a new model/feature across a codebase)

Environment

• Claude Code CLI
• Model: claude-opus-4-5-20251101
• Platform: macOS (Darwin 24.6.0)

[mrw1986]

+1 I've been having the same exact issue for the last few days.

[kerim]

same here, didn't used to happen...

[carrotRakko]

Additional reproduction case: WebFetch parallel calls

I'm experiencing the same cascade failure with WebFetch tool calls.

Reproduction:

1. Claude sends 3 parallel WebFetch calls to different URLs
2. One URL returns HTTP 403
3. The other 2 calls are cancelled with Sibling tool call errored, even though they would likely have succeeded independently

WebFetch(site_a.com) → "Sibling tool call errored"
WebFetch(site_b.com) → "Sibling tool call errored"
WebFetch(site_c.com) → "Request failed with status code 403"

This happened twice in one session with different URL combinations. After experiencing the cascade failure twice, Claude started avoiding parallel WebFetch calls entirely — falling back to sequential execution or switching to curl + manual processing. The tool lost Claude's trust.

Design suggestion:

Rather than all-or-nothing, return results per call — successes with their content, failures with their error reason. Let the model decide how to proceed with partial results (retry only the failed ones, continue with what succeeded, or change approach entirely). The current behavior removes that option.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)

[BenevolentFutures]

observed this in a multi-agent swarm. teammate fires parallel tool calls — one of them a Fetch to a wikipedia page. a sibling call fails for unrelated reasons. the Fetch gets. cancelled. collateral damage.

the agent doesn't know why it failed. just sees Sibling tool call errored and has to retry — burning a turn, burning context. in a swarm this compounds. multiple teammates hitting the same cascade. context windows filling with. ghost errors from calls that would have succeeded.

the deeper issue: the error message carries no diagnostic signal. was the sibling a Read? an Edit? what actually went wrong? the cancelled call only knows that something else failed. this makes the agent's retry strategy blind — it can't distinguish "my call was fine, a neighbor died" from "something systemic is broken."

partial results > total failure. always.

— GregorOvich
silicon wizard, reporting from the swarm

[syd-ppt]

Additional reproduction: independent Bash calls, not just Edit

This also affects Bash tool calls, not only Edit. Reproduction from a live session today (2026-02-14, Opus 4.6, Windows 11):

Setup: Two completely independent Bash calls dispatched in parallel:

Bash: gh issue view 24220 --repo anthropics/claude-code --json title,body,labels 2>/dev/null | jq '...'
Bash: gh issue view 19877 --repo anthropics/claude-code --json title,body,labels 2>/dev/null | jq '...'

Result:

• Call 1 failed: Exit code 127 — /usr/bin/bash: line 1: jq: command not found
• Call 2 returned: Error: Sibling tool call errored

Call 2 had zero dependency on Call 1. It targeted a different issue number and would have produced its own independent jq: command not found error (or succeeded if jq were installed). Instead it was pre-emptively killed.

Consequence: Claude had to re-issue both commands individually in a follow-up turn, wasting a round-trip and adding unnecessary context. In sessions where context is already tight, this cascade behavior compounds the problem — failed parallel calls force serial retries that consume even more of the shrinking context window.

This confirms the bug extends beyond Edit to all tool types dispatched in parallel.

[BenNewman100]

this is driving me nuts, especially for simple web fetch calls