Memory write corrupts thinking-block signature → 400 on every subsequent request

Memory write corrupts thinking-block signature → 400 on every subsequent request

Summary

When the auto-memory feature writes a memory on the same assistant turn that produced an extended-thinking block, the memory write mutates that assistant message. Thinking blocks carry a signature that the Anthropic API requires to be byte-for-byte identical on replay, so the next request is rejected with a 400 and the conversation becomes permanently wedged on the poisoned turn.

Error

API Error: 400 messages.23.content.4: `thinking` or `redacted_thinking` blocks in the
latest assistant message cannot be modified. These blocks must remain as they were in
the original response.

Environment

• Claude Code: 2.1.156
• Model: Opus 4.8 (1M context) — claude-opus-4-8[1m] (extended thinking on)
• OS: macOS 26.5, arm64
• Auto-memory feature: enabled (file-based, ~/.claude/projects/<project>/memory/)

Repro

1. Run a session with extended thinking enabled (default on Opus 4.8).
2. Reach a turn where the assistant both (a) emits a thinking block and (b) triggers a memory write — e.g. the user asks it to "record/remember" something, and the model recalls + writes memories in the same response.
3. Observed in-session footer at the moment of failure:

``
Recalled 1 memory, wrote 2 memories (ctrl+o to expand)
``

1. The next API request fails with the 400 above and keeps failing — the conversation cannot continue.

In the failing case the offending block was messages.23.content.4 — i.e. content index 4 of that assistant message was a thinking block that was no longer identical to what was originally returned.

Expected

Memory writes are a side effect and must not modify the assistant message that is part of the replayed transcript. Either:

• the memory-write machinery should append its bookkeeping outside the assistant turn (a separate system/tool message), never edit in place, or
• thinking blocks (and their signatures) must be preserved verbatim when any post-processing touches an assistant message.

Actual

The memory write edits the latest assistant message in place, invalidating the thinking-block signature, so the API rejects the transcript on the next call.

Impact

• Hard wedge: every subsequent request in the session 400s. The only recovery is rewinding past the poisoned turn (Esc-Esc) or /clear.
• The memory writes themselves do land before the error, so data isn't lost — but the live session is dead until rewound.
• Affects any thinking-enabled session that uses auto-memory, which is the default configuration on Opus 4.8.

Workarounds (for users hitting this)

• Esc-Esc to rewind to before the corrupted assistant turn, then re-send.
• If rewind doesn't clear it, /clear and resume — memories written before the error are already saved.
• Run thinking-off (/fast) for sessions where memory writes are frequent, to avoid the class entirely.

Suspected root cause

Post-turn memory processing performs an in-place edit of the assistant message (to inject the "Recalled N / wrote N memories" record or a related system-reminder), without round-tripping the original thinking/redacted_thinking blocks and their signatures. Any in-place mutation of an assistant message that contains signed thinking blocks will reproduce this.