Interrupted thinking-only message causes 400 error (patch part bypasses filter)

[grumpygordon]

Interrupting (Esc) while assistant is in thinking mode (reasoning only, no text output yet) breaks the session.

Next request fails with:

messages.X: all messages must have non-empty content except for the optional final assistant message

Related to #3101 but different root cause.

Repro:

1. Use thinking model (claude-opus with high variant)
2. Interrupt while "Thinking:" is displayed, before any text
3. Send another message → 400 error

Cause:
message-v2.ts:toModelMessage() line 483:

msg.parts.some((part) => part.type !== "step-start" && part.type !== "reasoning")

Aborted messages should be skipped if they only have step-start/reasoning. But the patch part (created on abort) passes this check, so the message gets included with only reasoning content. Anthropic rejects non-final assistant messages with only reasoning.

Fix:
Add patch to exclusion, or check for output-producing parts (text, tool) explicitly.

• macOS, dev build

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Missing context after network interruption #3101: Missing context after network interruption - Related issue mentioning the same error: 'all messages must have non-empty content except for the optional final assistant message'
• AI_APICallError: messages.157: all messages must have non-empty content except for the optional final assistant message #2655: AI_APICallError with the exact same error message about non-empty content (now closed)
• Empty message content causes Anthropic API errors during compaction #6446: Empty message content causes Anthropic API errors during compaction - Detailed analysis of how empty assistant messages with only tool calls/reasoning parts cause this error

The root cause appears to be similar: messages reaching the API with no text or output-producing content. Your specific case involves thinking-only content filtered out, while #6446 was about tool-only messages, but the underlying issue in toModelMessage() filtering logic seems related.

Feel free to ignore if your case is indeed the specific 'patch part' bypass issue described in your report.

[grumpygordon]

Sorry, created this accidentally with opencode, its my local build error...

[dan-cooke]

I'm also experiencing this all the time since the most recent update - if anyone stumbles upon here, you an fix it by Cmd + P > Fork and picking your most recent message

There is some bug with opencode that causes the context to be continuously empty, it seems to happen most frequently when you cancel an LLM output

[madeleineostoja]

Also experiencing this when interrupting thinking. Forking from a known good state is a good workaround

[ujjwaljainnn]

Also experiencing this when interrupting thinking. Forking from a known good state is a good workaround

If you didn't have file changes, you can also just click on your last message and run the revert command