fix(provider): preserve assistant message content when reasoning blocks present

[edevil]

Issue for this PR

Closes #16748

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Anthropic adaptive thinking (Opus 4.6+, Sonnet 4.6) emits empty text parts between thinking blocks:

[reasoning(sig1), text(""), reasoning(sig2), text("answer"), tool_use]

The empty text part originates from Anthropic itself — adaptive thinking with "omitted" mode (default on Opus 4.7+) emits content_block_start{type:"text"} immediately followed by content_block_stop with no deltas, as a structural separator between thinking blocks.

On replay, three separate gates reject an empty-string text part:

1. opencode normalizeMessages (transform.ts) — drops text === ""
2. AI SDK convertToLanguageModelPrompt — drops text === "" unless providerOptions != null
3. Anthropic server — rejects with "text content blocks must be non-empty"

And dropping the part entirely shifts reasoning-block positions, invalidating signatures with:

thinking or redacted_thinking blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response.

Once either rejection fires, the session is permanently broken — the corrupted history replays from storage on every retry.

The fix

Substitute a single space for empty text parts in assistant messages that contain signed Anthropic reasoning blocks. The space preserves the structural arrangement (the reasoning block positions) without triggering any of the three rejections. Signatures are on the reasoning block content, not on the text between them, so a non-empty placeholder keeps the arrangement valid.

const hasSignedReasoning = msg.parts.some(
  (p) => p.type === "reasoning" && (p.metadata as any)?.anthropic?.signature != null,
)
const text = part.text === "" && hasSignedReasoning ? " " : part.text

The gate self-identifies as Anthropic via signature presence (also covers Bedrock/Vertex Anthropic). Other providers' reasoning (OpenAI Responses, Gemini thinking, Copilot reasoningOpaque) don't position-validate, so their empty text continues to be filtered normally.

This is a single 3-line change in message-v2.ts where UIMessage parts are built from database parts. By the time the message reaches normalizeMessages() or the AI SDK's internal filters, the text is already " " (non-empty), so it passes all downstream checks naturally.

Historical context

• The normalizeMessages empty-text filter was added on Jan 5 (c285304a) before adaptive thinking existed (Feb 13, 0d90a22f9), so it was correct at the time
• Commit 33819932e (Apr 10) removed trimEnd() calls in processor.ts as a partial mitigation, but only helps when text is whitespace — the model can still emit truly empty text parts that trigger the bug
• Reproduced on v1.14.19 with claude-opus-4-7; no commits between v1.4.6 and current origin/dev fix it

How did you verify your code works?

• 3 new message-v2 tests: space substitution with signed reasoning; unsigned reasoning leaves empty text alone; no-reasoning messages leave empty text alone
• All existing tests pass (135 transform tests, 27 message-v2 tests)
• Typecheck passes across all 13 packages
• Binary built from this branch running in production with no thinking-block errors despite the trigger pattern appearing in sessions

Screenshots / recordings

N/A — backend logic change, no UI impact.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential Duplicate Found:

• PR fix(provider): skip empty-text filtering for assistant messages in normalizeMessages (#16748) #16750: "fix(provider): skip empty-text filtering for assistant messages in normalizeMessages (normalizeMessages() removes empty text parts between reasoning blocks, invalidating Anthropic thinking block signatures #16748)"
  • fix(provider): skip empty-text filtering for assistant messages in normalizeMessages (#16748) #16750

This PR appears to be directly related or a potential duplicate. It addresses the same issue (#16748) with the same root cause (empty-text filtering in normalizeMessages affecting assistant messages with reasoning blocks). Both PRs target the same problem with Anthropic's adaptive thinking signatures.

[edevil]

It seems this error message predates adaptive thinking so it must be something else.

[edevil]

I managed to confirm with a past session that this does indeed fix the issue in question.

[chan1103]

I hit another wrinkle while tracing the same bug locally.

Even after I stopped normalizeMessages from dropping the empty text, I still had empty assistant text getting removed later in the AI SDK request path when providerOptions wasn't set. In the broken sessions I was looking at, that was enough to shift the later reasoning blocks and Anthropic rejected the history.

I opened #21860 with a repro for that path too, in case it's useful.

[LuisDuarte1]

Verified the fix works and is at the correct layer. Sharing research findings and a small scoping refinement for your consideration.

Filter chain investigation: The empty text parts originate from Anthropic itself — adaptive thinking with "omitted" mode (default on Opus 4.7+, see anthropic-messages-options.ts:86-89) emits content_block_start{type:"text"} immediately followed by content_block_stop as a structural separator. The SDK faithfully passes this through as text-start → text-end with no deltas. On replay, three separate gates reject an empty-string text part:

1. opencode normalizeMessages (transform.ts:63-68) — drops text === ""
2. AI SDK convertToLanguageModelPrompt — drops text === "" unless providerOptions != null
3. Anthropic server — rejects with text content blocks must be non-empty

And dropping the part entirely shifts reasoning-block positions → thinking blocks in the latest assistant message cannot be modified.

Scoping refinement suggestion: the current condition hasReasoning triggers for any provider with reasoning parts. The only reason position-preservation matters is Anthropic's cryptographic signatures — other providers' reasoning (OpenAI Responses, Gemini thinking, Copilot reasoningOpaque) don't position-validate. Suggest narrowing to:

const hasSignedReasoning = msg.parts.some(
  (p) => p.type === "reasoning" && p.metadata?.anthropic?.signature != null,
)
const text = part.text === "" && hasSignedReasoning ? " " : part.text

This self-identifies as Anthropic via signature presence (also covers Bedrock/Vertex Anthropic), avoids threading provider info into toModelMessagesEffect, and lets the normal empty-text filter handle the remainder.

Tests that would pair nicely:

• Negative test: reasoning present without metadata.anthropic.signature → empty text stays empty and gets filtered as usual.
• End-to-end: drive the processor with the actual Anthropic stream shape (reasoning-start/delta/signature_delta/end → text-start/text-end with no deltas → reasoning → text-delta) and assert stored text: "" and converted text: " ".

Out of scope for this PR: the redundant empty-text branch in normalizeMessages could be cleaned up in a follow-up since AI SDK Filter 2 covers assistant text anyway, but that's orthogonal.

[omer-koren]

Ran into a gap while verifying this fix against AWS Bedrock Claude Opus 4.7 — the hasSignedReasoning gate only matches metadata.anthropic.signature, but Bedrock and Vertex store the signature under their own provider namespaces:

• metadata.bedrock.signature — AWS Bedrock
• metadata.vertex.signature — GCP Vertex AI

Result: on Bedrock/Vertex the gate never fires, the empty-text substitution is skipped, and the cannot be modified error still triggers on compact.

Confirmed by inspecting a real session's reasoning part metadata in SQLite:

{ "type": "reasoning", "text": "...", "metadata": { "bedrock": { "signature": "Es4EClk..." } } }

Opened a small follow-up against @edevil's branch with a 3-namespace check + Bedrock/Vertex test coverage: edevil#1

The rest of the PR works great — verified on a production Bedrock session that was reliably reproducing the issue on manual compact; no longer triggers after applying both fixes.

[edevil]

Thanks @omer-koren for catching the Bedrock/Vertex gap and the clean follow-up.

Rebased on current dev and cherry-picked the fix from edevil#1 (authorship preserved). The hasSignedReasoning gate now matches anthropic, bedrock, and vertex signature namespaces, with paired tests for the Bedrock and Vertex paths. Tests + typecheck green across all packages.

edevil#1 can be closed.