Repository navigation
[BUG] : Anthropic tool_use / tool_result pairing broken on 3.88–3.90 (both missing and unexpected IDs), even without images #2098
Description
Extension: 3.88.0 and 3.90.0
Provider: Anthropic (claude-opus-5-5, claude-fable-5-1)
OS: macOS
Summary
Almost every task now fails with an Anthropic 400 because the request Zoo Code sends violates tool_use / tool_result adjacency. This started getting bad around 3.88 and is constant on 3.90. It happens on normal tool turns, not only when images are involved.
Errors (both directions)
text400 invalid_request_error
messages.N: tool_use ids were found without tool_result blocks immediately after: toolu_...
Each tool_use block must have a corresponding tool_result block in the next message.
text400 invalid_request_error
messages.N.content.2: unexpected tool_use_id found in tool_result blocks: toolu_...
Each tool_result block must have a corresponding tool_use block in the previous message.
When it happens
Parallel tool calls
Interrupted / cancelled tools
Any turn that returns or attaches images (worse, but not required)
After sliding-window / history compaction
New tasks and long tasks; not limited to one corrupted history file
Actual payload shape (broken)
Assistant:
texttool_use id=A
tool_use id=B
User (what gets sent):
text[0] tool_result A
[1] image ← or text / other content
[2] tool_result B ← Anthropic never sees this as “immediately after”
Or a tool_result whose tool_use is missing from the previous assistant message entirely.
Expected
text[0] tool_result A
[1] tool_result B
[2] image / text (optional, after all results)
And any interrupted tool_use gets a synthetic error tool_result before the request is sent. Orphan tool_results are dropped.
Impact
Task is stuck; retries re-send the same bad payload
Developer: Reload Window sometimes clears it, often doesn’t
Manual edit of api_conversation_history.json works once, then the next tool turn corrupts it again
Happens across projects on 3.90.0
Likely area
Request assembly in the path that builds the next user message after tool execution (getEffectiveApiHistory or equivalent), plus the 3.90 “scope tool state to each tool call” change. Orphan filtering after truncation (the Roo Code fix in #11030) also needs to run on every path, not only the summary path.
Workaround
Reload Window, or quit VS Code and rewrite history so all tool_results are contiguous and first, and drop orphans. Not viable for normal use.
Activity
PierrunoYT commentedon Oct 20, 2026
Working on this!
fix(task): normalize tool_use/tool_result pairing in outgoing requests
karlg100 commentedon Oct 30, 2026
I was also seeing recurring HTTP 400
tool_use/tool_resultpairing errors on Zoo Code 3.82.2, using VS Code with the Anthropic provider through an internal LiteLLM proxy to Bedrock.Confirmed fix: I tested a local backport of PR #2113 onto 3.82.2, packaged as 3.82.2001. The reported error is now resolved in my setup.
The diagnostic export showed this sequence, with identifiers simplified:
There was no intervening assistant message between the two user turns. Merging those turns placed the duplicate result at
messages.16.content.3, matching the location reported by the API.The export contained 84 tool calls and 86 tool results. Applying the backported normalization produced 84 correctly paired results, preserving the stored history. This was also covered by an added request-construction regression test that fails when the normalization call is removed.
The tested backport is available here:
3.82.2 backport, commit ba9d8cd.
This provides confirmation that #2113 addresses this duplicate-result failure on 3.82.2 as well. The original trigger that writes the duplicate history remains unconfirmed.
Could you please prioritize this issue and review of PR #2113 for inclusion in the next release? This recurring error interrupts normal work, and the backport has resolved it in my setup. Shipping the fix in an official release would let us stop relying on a locally maintained build.