claude-code - 💡(How to fix) Fix Regression: #12311 thinking-block compaction fix (v2.1.156) is incomplete — still reproduces on v2.1.158 with claude-opus-4-8

Summary

Issue #12311 ("Auto-compact fails with Opus extended thinking blocks") was closed as completed, and the v2.1.156 CHANGELOG states:

Fixed an issue when using Opus 4.8 where thinking blocks were modified, leading to API errors.

The fix is incomplete. The same 400 invalid_request_error still occurs on v2.1.158 (two minor versions after the fix) with claude-opus-4-8 — the exact model the .156 changelog names. The .156 patch appears to have closed one corruption path but not all of them for long extended-thinking sessions that hit auto-compact.

Environment

• Claude Code version: 2.1.158 (post-fix; fix landed in 2.1.156)
• Model: claude-opus-4-8
• Platform: darwin (macOS 24.6.0), local binary install
• Date observed: 2026-05-30

Error (verbatim, from an isApiErrorMessage event in the transcript)

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

The error then repeats on every subsequent request, bricking the session — including /compact itself, so the user cannot compact their way out.

Relationship to prior reports

• #12311 (canonical, closed/locked) — reported on Opus 4.5, pre-fix.
• #63072 (open, marked duplicate) — reported on v2.1.153, which is also pre-fix (before 2.1.156).
• This report is specifically POST-fix: v2.1.158, after the 2.1.156 patch. That is the new information — the shipped fix does not fully resolve the bug.

Steps to reproduce

1. Start a session on claude-opus-4-8 with extended thinking enabled.
2. Run a long conversation (heavy tool use + many thinking turns) until it grows large enough to trigger auto-compact.
3. On the auto-compact replay, the API rejects the request with the 400 above at messages.N.content.M.
4. Every subsequent call 400s identically; the session is unrecoverable in place.

Likely mechanism (from on-disk transcript inspection)

During the auto-compact rewrite, the signature on a thinking block in the latest assistant message no longer matches its content — the harness mutates/reorders content blocks (and redacted_thinking blocks, which are memory-only, are lost on reconstruction). The signed block then fails server-side validation. The .156 fix reduced but did not eliminate this on Opus 4.8 at scale.

Impact

• Severity: High — complete loss of the live session's forward progress; auto-compact (a default, non-optional path for long sessions) is the trigger.
• Workarounds that do work today:
  • Run long/marathon sessions on a Sonnet model (no extended-thinking blocks → bug cannot occur).
  • To recover a bricked session: quit, strip the orphaned/empty-signed thinking/redacted_thinking blocks from the on-disk transcript, then --resume (the stripped blocks have empty text on disk, so removal is non-destructive). This only works on reload — a live session holds the corrupted state in memory.

Ask

Please reopen/extend the #12311 fix. The 2.1.156 patch did not cover all corruption paths for claude-opus-4-8 during auto-compaction; it is still reproducible on 2.1.158.