[BUG] Mode/permission changes mid-tool-loop (effortLevel: xhigh) poisons entire session

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

With extended thinking active (effortLevel: xhigh puts a thinking block on the first
assistant turn), changing session state in the middle of an active tool-use loop causes
the next request to fail with:

API Error: 400 messages.1.content.N: 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 this fires, EVERY subsequent turn in the session replays the same corrupted history
and returns the identical 400 — the session is permanently poisoned and unusable.

What Should Happen?

State changes during a tool loop should not mutate the preserved thinking/redacted_thinking
blocks of earlier assistant turns. Thinking blocks must round-trip byte-for-byte (incl.
signature). Related to thinking blocks bug filed earlier but appears to be my individual root cause.

Error Messages/Logs

Steps to Reproduce

1. Set "effortLevel": "xhigh" in settings.json.
2. Start a session and give a task that triggers a multi-step tool-use loop.
3. While the agent is actively running tools (mid-loop), change session state — e.g.

toggle permission mode with Shift+Tab (default → auto-accept), and/or submit a new prompt.

1. The next assistant generation returns the 400 above, referencing a thinking block in

messages.1 (the first assistant turn).

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.154

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Reproduced in two consecutive sessions. In both, the failure occurs mid-tool-loop (the
transcript entry immediately preceding the error is a tool_result) and the offending
block is in messages.1:

• Session A: error at messages.1.content.18. The transcript shows a permission-mode

change default → auto on the line immediately before the first error. After it broke,
4 consecutive turns returned the same 400.

• Session B: error at messages.1.content.19, same mid-loop pattern, preceded by a burst

of last-prompt / ai-title / mode metadata entries.

(Branch analysis ruled out message rewinding/editing as the cause — the only "branches" in
the transcript were normal tool_use → tool_result linkages.)