PreToolUse hook (`rtk hook claude`) corrupts interleaved `thinking` blocks → Anthropic API 400 "thinking blocks cannot be modified", hard-locking the session

[itspokchop93]

Summary

When extended/interleaved thinking is enabled in Claude Code, RTK's PreToolUse
hook (rtk hook claude) appears to mutate the assistant message while rewriting a
tool call. If that assistant message also contains a thinking block, the next
API request is rejected by Anthropic with:

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

Because the corrupted message stays in conversation history, every subsequent turn
re-sends it and fails identically — the session is hard-locked and unrecoverable
without removing the message.

Why I believe RTK is involved

• RTK is registered as PreToolUse -> rtk hook claude (rewrites tool calls before they run).
• The failure only occurs on long, tool-heavy turns where interleaved thinking
  produces an assistant message that mixes thinking blocks with multiple tool_use
  blocks (the API error referenced content.13, i.e. a thinking block among the tool calls).
• Anthropic requires thinking/redacted_thinking blocks to be returned byte-for-byte
  unchanged. A PreToolUse hook that rewrites the tool_use inside that same message is
  the most direct candidate for breaking that invariant.

Steps to reproduce

1. Use Claude Code with extended/interleaved thinking enabled.
2. Install RTK and let it register its PreToolUse hook (rtk hook claude).
3. Give the agent a task that triggers many bash tool calls in a single turn
   (e.g. a multi-step debugging task that runs ~15+ commands) so thinking blocks
   and tool_use blocks interleave in one assistant message.
4. Observe the API 400 error above. The session then fails on every retry.

Expected behavior

Rewriting a tool command should never alter sibling thinking/redacted_thinking
blocks (or cause them to be re-serialized in a way that changes their signature).
Thinking blocks must be passed through untouched.

Actual behavior

The thinking block in the latest assistant message is treated as modified by the
Anthropic API, producing a 400 and locking the session.

Environment

• RTK version: 0.38.0 at time of failure (also reproduced conceptually on 0.42.0; no
  thinking-related fix found in 0.42.0 changelog)
• Install method: Homebrew (/opt/homebrew/bin/rtk)
• OS: macOS (Darwin 24.3.0)
• Client: Claude Code (Anthropic), model: Claude Opus 4.x, interleaved thinking enabled
• Hook config (from ~/.claude/settings.json):
  • SessionStart -> ~/.claude/hooks/rtk-ensure-hook.sh
  • PreToolUse -> rtk hook claude

Suggested fix / mitigation

When processing the PreToolUse payload, RTK should treat any thinking /
redacted_thinking content as immutable and pass it through verbatim, ensuring no
re-serialization of the assistant message alters those blocks. A regression test that
runs the hook against an assistant message containing interleaved thinking + tool_use
blocks and asserts the thinking blocks are byte-identical afterward would catch this.

[pszymkowiak]

wshm · Automated triage by AI

🔍 Automated Triage

🐛 Category	bug
🟠 Priority	high
🎯 Confidence	91%

Summary

RTK's PreToolUse hook corrupts sibling thinking/redacted_thinking blocks when rewriting tool_use blocks, causing Anthropic API 400 errors that permanently lock the session; fix by treating thinking blocks as immutable pass-throughs during hook rewrite.

---

Triaged automatically by wshm · This is an automated analysis, not a human review.

[eggrollofchaos]

Confirming this on another workstation, with a cross-reference that should help triage.

Same failure here: the PreToolUse hook re-serializes an assistant message containing interleaved thinking blocks, and the next request 400s with

messages.N.content.M: `thinking` or `redacted_thinking` blocks in the latest assistant message cannot be modified

It recurs on every retry because the corrupted message persists in history. In our case the rejected assistant message had a thinking block immediately preceding the rewritten tool call (messages.3.content.9, the preceding block being thinking).

Cross-reference for triage: the identical error is also being reported against Claude Code itself at anthropics/claude-code#63396 (as "Variant 2"). That issue bundles two unrelated failures: (a) a request-builder bug that places role:"system" elements inside messages (transcript-independent), and (b) this thinking-block corruption. For anyone running a PreToolUse hook that rewrites tool calls, (b) is very likely this hook, not Claude Code — the hook mutates the stored assistant message, so the byte-modified thinking block is what gets resent. Worth flagging so the thinking-block reports over there are not mis-attributed.

Repro confirmation: matches the reported steps — interleaved thinking enabled, hook installed, a turn with many tool calls so thinking and tool_use blocks interleave.

The suggested fix looks right: treat thinking/redacted_thinking content as immutable and pass it through byte-for-byte, with a regression test asserting the blocks are unchanged after the hook runs. Until then the only mitigation we found is disabling the hook — there is no transcript-side repair, since the signed block can't be reconstructed once a byte changes.