[错误]Claude Code session becomes permanently unrecoverable after 424 error "Invalid data in redacted_thinking block"

Resolved 💬 4 comments Opened May 27, 2026 by LeeXY1998 Closed Jun 27, 2026

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?

Description

During a long-running session in the VS Code Claude Code extension, the
session suddenly returned a 424 error:
"Invalid data in redacted_thinking block".

After this error occurred, every subsequent message — including clicking
"Continue" — returned the exact same error, leaving the entire conversation
permanently stuck with no way to recover within that session.

Error message

API Error: 424 {"code":424,"msg":"response error, status_code=400,
error={\"error\":{\"message\":\"..content.135: Invalid data in
redacted_thinking block (request id: 20260527121256486607602Ao6p7lBlD)\",
\"type\":\"\\u003cnil\\u003e\",\"param\":\"\",\"code\":null}}
[trace_id=1e6e317b2f9b8c1c4971c2252f5be496]","data":null}

Environment

  • Client: VS Code Claude Code extension (CLI v2.1.131)
  • Model: Claude Opus 4.7 (1M context)
  • Routing: StepCode gateway
  • Time: 2026-05-27 20:12 (UTC+8)
  • Session file: ~/.claude/projects/-Users-jyxc-dz-0101381/

ef798427-904f-4090-81dc-988f59d66419.jsonl

Trace IDs (two consecutive failures, same behavior, different IDs)

  • trace_id: 1e6e317b2f9b8c1c4971c2252f5be496

request_id: 20260527121256486607602Ao6p7lBlD

  • trace_id: 5a62a5ce0ca3593c57d241d0150ff57d

request_id: 202605271215518739465513ot0rPh6y

Trigger scenario

While running the /fewer-permission-prompts skill, the model completed
several rounds of tool calls (Bash, Read, etc.) successfully. The error
appeared when the model was generating the next response (with extended
thinking enabled). The error points to content[135] in the message history,
where a redacted_thinking block's data field is rejected as invalid.

Suspected root cause

The model produced a redacted_thinking block (extended thinking output that
was safety-filtered) in an earlier turn. This block was persisted into
session history in a corrupted form. Every subsequent request replays the
full history, so the broken block is re-sent on every turn — and the
Anthropic API consistently rejects it. Hence the deterministic 424 loop.

Expected behavior

  1. The model/API should not emit redacted_thinking blocks with invalid

data fields (server-side issue).

  1. Even if a corrupt block exists, the routing layer or client should

detect it and degrade gracefully — e.g., strip the broken block, or
prompt the user to start a fresh session automatically — instead of
leaving the conversation permanently unrecoverable.

Impact

A week's worth of accumulated session context was lost. The user was
forced to start a new conversation from scratch, losing all prior context
and interrupting active work.

What Should Happen?

Expected behavior

  1. The model/API should not emit redacted_thinking blocks with invalid

data fields (server-side issue).

  1. Even if a corrupt block exists, the routing layer or client should

detect it and degrade gracefully — e.g., strip the broken block, or
prompt the user to start a fresh session automatically — instead of
leaving the conversation permanently unrecoverable.

Error Messages/Logs

Steps to Reproduce

Trigger scenario

While running the /fewer-permission-prompts skill, the model completed
several rounds of tool calls (Bash, Read, etc.) successfully. The error
appeared when the model was generating the next response (with extended
thinking enabled). The error points to content[135] in the message history,
where a redacted_thinking block's data field is rejected as invalid.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.131 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗