claude-code - 💡(How to fix) Fix [BUG] Mode/permission changes mid-tool-loop (effortLevel: xhigh) poisons entire session

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• 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.
4. 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.)