Error: Sibling tool call errored

This message is not a diagnosis. The model issued several tool calls in one turn, one of them failed, and the batch was abandoned — so the remaining calls were filled in with this text to keep the conversation structurally valid. It tells you nothing about the tool it is attached to. It is not an API error, not a quota, not a context limit, and not evidence that the tool you are looking at is broken. The error you need is a different tool result in the same turn, and the rest of this page is about finding it and about what this placeholder quietly fails to tell you.

Why the string exists at all

The Messages API requires every tool_use block in an assistant message to be answered by a matching tool_result in the next user message. You cannot answer three of five calls and leave two unanswered; the next request would be rejected as malformed before the model ever saw it.

That constraint is what produces this text. When one call in a parallel batch fails in a way that stops the batch, the client still has to send something back for each of the others, so it writes a placeholder into each one. The placeholder is bookkeeping — a structural requirement of the message format being satisfied — and it is generated by your client, not returned by the provider.

Knowing that changes what you do next. There is no configuration behind this string, no server to restart, and no setting to adjust. Reading it more closely will not yield more information, because there is none in it.

Finding the error that actually happened

In the interface, look at the same turn, not the previous one. A batch is the group of tool calls the model issued together in a single assistant message. Exactly one of them — occasionally more — carries a real failure; every other one carries this placeholder. Scanning that group takes seconds once you know the group is the unit to scan.

When the interface has collapsed the turn, or the session has moved on, the transcript has it. Sessions are stored as JSONL at ~/.claude/projects/<project>/<session-id>.jsonl, where <project> is the working directory path with non-alphanumeric characters replaced by - (CLAUDE_CONFIG_DIR relocates this if you have set it; on Windows ~/.claude means %USERPROFILE%\.claude). Find the last assistant message containing more than one tool_use block, then read the tool_result blocks in the user message that follows it. They correspond by tool_use_id. Discard every one whose content is this placeholder; what is left is the failure.

If nothing is left — if every result in the batch is a placeholder — the batch was not aborted by a tool at all. That happens when the turn was interrupted or the request itself failed, and it points you at the session rather than at any tool.

What this message does not tell you: whether your tool ran

This is the part worth slowing down for, because the natural assumption is convenient and unsafe.

The placeholder means no usable result was recorded. It does not mean the tool did not execute. Parallel calls are dispatched together; a call can reach the tool, do its work, and have its result discarded when the batch is torn down. From the transcript, “cancelled before it started” and “completed and thrown away” look identical.

The client’s own behavior reflects that uncertainty: failures that arrive after a tool call has completed are deliberately not retried, precisely because re-running could execute the same tool calls twice. The system treats this ambiguity as real, and so should you.

So if the batch contained anything with a side effect — a file write, a commit, a migration, a deploy, a message sent, a resource created — verify the side effect in the world before you assume it did not happen. Check the file, git status, the target system. Re-running a turn on the assumption that nothing happened is the way this error stops being cosmetic and starts creating duplicates.

Is retrying useful?

No — there is nothing here to retry.

This call did not fail on its own terms, so “retry it” has no meaning. What you could retry is the turn, and until the real failure is fixed the turn will collapse the same way, because the batch will contain the same failing call.

There is also a cost to the reflex. Re-sending the turn re-runs every call in the batch, including the ones that may already have completed their side effects before the teardown. On a batch of reads that is merely wasteful. On a batch containing a write, it is how you end up with the same change applied twice.

The correct sequence is: find the real error, fix or work around that, then re-run the turn once — and verify side effects first if the batch touched anything stateful.

Once you have the real error, the branches are ordinary

The hard part was retrieval; the diagnosis after that is the same as it would have been if the error had arrived alone.

An MCP tool returned too much — the sibling reports a size ceiling rather than a failure, and the fix is on the call, not the batch. That is the MCP response-too-large page.
An MCP server died — the sibling names a closed connection, and every tool from that server will keep failing for the rest of the session. See what a closed MCP connection actually means.
A permission prompt was denied or auto-denied — the batch stops on the denial. Nothing is broken; the answer was no.
A tool timed out — the sibling says so, and the discriminator is whether it times out reproducibly on the same input or occasionally on any input.
The turn was interrupted — you pressed Esc, or something upstream cancelled. Every result is a placeholder, and there is nothing to fix.

When it keeps happening

If whole batches collapse regularly, treat it as a reliability signal rather than a series of unrelated incidents. Parallel execution amplifies a single flaky tool: one MCP server that fails one call in ten will, in a session that issues batches of several calls, take down a noticeably larger share of turns than its own failure rate suggests. The lever is not the batching — you do not control it directly — it is the tool. Find the one that keeps appearing as the real error across several collapsed turns, and either fix it or disconnect it for the session. Removing one unreliable server often removes what felt like a general instability.

Confirming you are done

The confirmation is not “the message is gone” — it disappears as soon as the turn succeeds for any reason, including luck.

Re-run a turn that dispatches the same set of tools, then open the transcript for that turn and check that every tool_result carries a real result and no placeholder remains. If the underlying failure was intermittent — a flaky network call, a server that dies under load — do it twice, because one clean batch is indistinguishable from a transient problem taking a turn off. And if the original batch had side effects you verified earlier, check them again afterward, so that “it worked” does not quietly mean “it worked twice”.

If the batch broke your history rather than just your turn — requests failing after an interrupt, with a message that names tool use concurrency and points you at /rewind — the repair is rewinding the conversation, not re-running the tools. If every request fails before any tool runs at all, look at the assembled tool array instead: a duplicate tool name is rejected at validation and never reaches the stage where batches exist. The AI coding error triage tool is built around the question this page turns on — whether the message in front of you is the failure or a consequence of one somewhere else.