You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
AI_APICallError: tool_use ids were found without tool_result blocks immediately after #1662
AI_APICallError: messages.13:
`tool_use` ids were found without
`tool_result` blocks immediately
after:
toolu_01CfJCsh21fK1pAXsXWYJYBA,
toolu_01NoqnwsaxoK3AYM2FyrxmjN.
Each `tool_use` block must have a
corresponding `tool_result` block
in the next message.
happpens regularly . conversation cannot be continued without switching to a different model
did this happen after an abort or something? Like you aborted a request then tried to continue convo?
this commonly seems to be a trigger, but is not the sole trigger. it can occur randomly. it can be mitigated by undoing to the message before the message which triggers this error
I am getting this error on 0.5.28 with opus 4.1 as the planning agent. I exited and restarted opencode and the problem persisted after resuming the session.
I suspect there is 'corruption' in the history as I can also trigger this error by running /compact after it occurs.
messages.453: `tool_use` ids were found without `tool_result` blocks immediately after: toolu_01BmQLHErsVFKDSd51CUnUXg. Each `tool_use` block must have a corresponding `tool_result` block in the next message.
Edit 1:
Switching other model (to Claude Opus 4.1) does not help.
I'm also facing this one, it's happening across at least Sonnet 4, Sonnet 4.5 and Opus 4.5. I'm seeing it when the agent reads a pdf file (in the same project). Once this happens it corrupts the conversation, I need to undo the prompt that caused it, and can then continue, but to no avail to read the PDF and get past that point. Switching to a non-Anthropic model of course enables it to proceed (as the error is being returned from the Anthropic API). I can then switch back to the Anthropic model and continue, so there is a workaround albeit not ideal!
@sawy3r now that's interesting would u be able to share your session reproducing that?
opencode export > session.json
Sure can!
See attached, I've redacted it slightly and truncated the PDF base64 data that was included (I've also attached the PDF for your reference as well. It happens with any I try at the moment).
I set this session up to attempt to replicate it, and it happened right away at the first prompt, where I asked the agent to read a PDF.
ctrl+x u will undo the previous message. Undo until the error message disappears from the chat. This can happen when a message response was interrupted and the result from the message wasn't created. So, undo until chat history is at a good stage and then continue again.
Reacted by Max Tuzzolino, selim ataballyev, Daniele Polencic, Julian Vives, bil9148 and Andrew Eskenazi
ctrl+x u will undo the previous message. Undo until the error message disappears from the chat. This can happen when a message response was interrupted and the result from the message wasn't created. So, undo until chat history is at a good stage and then continue again.
Adding detailed diagnostics from my investigation:
Root Cause
When a tool call is interrupted (network timeout, proxy error, abort), OpenCode records the tool_use block but does NOT insert a corresponding tool_result block. This permanently corrupts the session — every subsequent message is rejected with the tool_use without tool_result validation error.
Key Evidence
The error fires 1-4ms after user_message, proving it's a pre-request validation failure, not a network issue:
Compounding issue: session.error often fires with an empty error field, and the TUI shows zero feedback. The user sees a silent hang with no indication of what happened.
Suggested Fix
Always insert a synthetic tool_result with error status when a tool_use does not complete, regardless of the interruption cause. This maintains Claude API message format compliance and prevents permanent session corruption.
Workaround
I wrote a plugin that hooks session.error, scans all messages for orphaned tool_use blocks (pending/running state), and calls session.revert() to remove the broken message. Combined with tui.showToast() to surface the error. Happy to share if helpful.
Environment
Windows 11, OpenCode latest (CLI + Desktop)
Provider: API proxy → AWS Bedrock → Claude Sonnet 4 / Opus 4
Frequency: Multiple times daily, especially in sessions with many tool calls
Activity
AnsgarH1 commentedon Aug 18, 2025
I also got the error on MacOS with OpenCode v0.5.5
rekram1-node commentedon Aug 18, 2025
did this happen after an abort or something? Like you aborted a request then tried to continue convo?
ShamanicArts commentedon Aug 18, 2025
this commonly seems to be a trigger, but is not the sole trigger. it can occur randomly. it can be mitigated by undoing to the message before the message which triggers this error
esafak commentedon Aug 29, 2025
I am getting this error on 0.5.28 with opus 4.1 as the planning agent. I exited and restarted opencode and the problem persisted after resuming the session.
I suspect there is 'corruption' in the history as I can also trigger this error by running
/compactafter it occurs.namchuai commentedon Nov 21, 2025
I'm also faced this issue
Edit 1:
Switching other model (to Claude Opus 4.1) does not help.
rekram1-node commentedon Nov 21, 2025
Yeah this is a bug with the anthropic api itself it sends back duplicate content or something and messes up the state of the client.
We can fix it on our end its just a little messy reordering things all the time
sawy3r commentedon Dec 15, 2025
I'm also facing this one, it's happening across at least Sonnet 4, Sonnet 4.5 and Opus 4.5. I'm seeing it when the agent reads a pdf file (in the same project). Once this happens it corrupts the conversation, I need to undo the prompt that caused it, and can then continue, but to no avail to read the PDF and get past that point. Switching to a non-Anthropic model of course enables it to proceed (as the error is being returned from the Anthropic API). I can then switch back to the Anthropic model and continue, so there is a workaround albeit not ideal!
Running opencode binary version 1.0.157 on MacOS
rekram1-node commentedon Dec 16, 2025
@sawy3r now that's interesting would u be able to share your session reproducing that?
opencode export > session.jsonsawy3r commentedon Dec 17, 2025
Sure can!
See attached, I've redacted it slightly and truncated the PDF base64 data that was included (I've also attached the PDF for your reference as well. It happens with any I try at the moment).
I set this session up to attempt to replicate it, and it happened right away at the first prompt, where I asked the agent to read a PDF.
sessionNew-redacted.json
AI_APICallError_
tool_useids were found withouttool_resultblocks immediately after · Issue #1662 · sst_opencode.pdftagpro commentedon Dec 20, 2025
ctrl+x uwill undo the previous message. Undo until the error message disappears from the chat. This can happen when a message response was interrupted and the result from the message wasn't created. So, undo until chat history is at a good stage and then continue again.soapergem commentedon Feb 6, 2026
I'm also getting this same error quite a lot lately, on Claude Sonnet 4.5
drewesk commentedon Feb 26, 2026
thanks for saving my life @tagpro
mmack commentedon Mar 6, 2026
same here
ArchishmanSengupta commentedon Mar 26, 2026
is this solved?
liqiyuan3 commentedon Apr 7, 2026
Adding detailed diagnostics from my investigation:
Root Cause
When a tool call is interrupted (network timeout, proxy error, abort), OpenCode records the
tool_useblock but does NOT insert a correspondingtool_resultblock. This permanently corrupts the session — every subsequent message is rejected with thetool_use without tool_resultvalidation error.Key Evidence
The error fires 1-4ms after user_message, proving it's a pre-request validation failure, not a network issue:
Compounding issue:
session.erroroften fires with an empty error field, and the TUI shows zero feedback. The user sees a silent hang with no indication of what happened.Suggested Fix
Always insert a synthetic
tool_resultwith error status when atool_usedoes not complete, regardless of the interruption cause. This maintains Claude API message format compliance and prevents permanent session corruption.Workaround
I wrote a plugin that hooks
session.error, scans all messages for orphanedtool_useblocks (pending/running state), and callssession.revert()to remove the broken message. Combined withtui.showToast()to surface the error. Happy to share if helpful.Environment
fix(session): stabilize step timeline scrolling (anomalyco#1662)