V2: errored-message replay can 400 with Anthropic thinking + tool use

[rekram1-node]

Problem

In the V2 session core, replaying history that contains an errored assistant message can produce a request Anthropic rejects with a 400 when extended thinking is enabled.

reuseProviderMetadata requires message.error === undefined (packages/core/src/session/runner/to-llm-message.ts:114), so an aborted/failed step drops all reasoning state on replay — both signed thinking (anthropic.signature) and redacted thinking (anthropic.redactedData) — while still replaying that same message's tool_use parts.

Anthropic requires a tool_use block to be preceded by its thinking/redacted_thinking block when thinking is enabled. Replaying tool_use without the reasoning block yields a 400 from the API.

Impact

Multi-turn thinking + tool-use conversations with Anthropic break after an interrupt or failure mid-step: the follow-up request replays the errored message's tool calls stripped of their reasoning blocks and the provider rejects it.

Scope

• Pre-existing behavior; unrelated to and not introduced by feat(ai): round-trip Anthropic redacted thinking blocks #38614 (which added redacted thinking round-trip support in packages/ai). Signed thinking is affected identically.
• The errored-message guard is otherwise a deliberate design decision, so the fix should be deliberate too.

Possible directions

• Relax the message.error === undefined guard in to-llm-message.ts so reasoning provider state is reused for errored messages when provider+model match, or
• Drop the errored message's tool-call parts alongside the reasoning so the replayed message stays self-consistent (no orphaned tool_use).

Either way, the invariant to preserve is: never replay a tool_use part to Anthropic without its preceding thinking block while thinking is enabled.

[MagnumGoYB]

I'd like to take this one, if the direction is still open.

Two things I'd like to confirm before writing any code, since the issue notes the errored-message guard is a deliberate decision:

1. Which direction do you prefer? Of the two listed, dropping the errored message's tool-call parts alongside the reasoning seems safer to me than relaxing the message.error === undefined guard, because it keeps the replayed message self-consistent without re-introducing provider state from a step that never completed. But I may be missing why the guard is scoped the way it is.

2. Should the PR target dev or v2? The guard is present on both (to-llm-message.ts:73 on dev, :114 on v2, which matches the line in the issue). I'd rather ask up front, since PRs based on v2 seem to get flagged needs:issue because GitHub doesn't populate closing references for a non-default base.

Happy to add regression coverage for the invariant either way: never replay a tool_use part without its preceding thinking block while thinking is enabled.

[MagnumGoYB]

Follow-up before I write anything, because a local check changed my read of the two directions.

The current behavior is not just incidental, it is pinned by an existing test: packages/core/test/session-runner-message.test.ts:330, "drops provider-native continuation metadata from failed assistant turns". It asserts that an errored turn replays reasoning with providerMetadata: undefined and keeps the tool-call / tool-result parts. So that test encodes exactly the shape this issue says Anthropic rejects.

Baseline on dev: 6 pass in that file.

That means either direction has to touch that test, which makes the choice less about the fix site and more about which invariant you want asserted:

• Relaxing the message.error === undefined guard means the test's premise changes: errored turns would keep signed/redacted thinking when provider+model match. The test would assert reuse instead of dropping.
• Dropping the errored turn's tool-call parts keeps the "no provider state reused" property the test is protecting, and instead removes the orphaned tool_use. The test's reasoning assertion stays as-is; its tool assertions go away.

The second still looks preferable to me for that reason: it preserves what the existing test was written to protect. But that test's title suggests the drop was a deliberate cross-provider decision (the fixture is OpenAI reasoningEncryptedContent, not Anthropic), so I don't want to repurpose it without a maintainer's call.

One more thing worth flagging: the same guard also feeds the OpenAI path at line 299 ("restores OpenAI encrypted reasoning metadata"), so relaxing it is not Anthropic-scoped.

Still happy to do this, just want the direction confirmed first given the test coupling. Same question on dev vs v2 as above.