Summary

When a session contains an assistant message with thinking or redacted_thinking blocks (produced by adaptive reasoning mode) and the prompt cache is invalidated (e.g. system prompt change), Anthropic's API rejects all subsequent requests with:

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

This permanently bricks the session. No user recovery path exists short of /reset.

Steps to Reproduce

1. Have a session run with thinking=adaptive (or any thinking-enabled mode) such that an assistant turn produces a thinking block in the transcript
2. Trigger a cache miss — e.g. a system prompt change (AGENTS.md update, workspace file change, config change that alters the bootstrap context)
3. Send any subsequent message to the session
4. Observe: Anthropic API returns 400 with thinking block modification error
5. OpenClaw's session file repaired: rewrote 1 assistant message(s) repair pass does NOT resolve the issue
6. Session is permanently stuck — every request fails with the same error

Expected Behavior

One or more of:

• Auto-recovery (preferred): On this specific error class (thinking block modification), OpenClaw should automatically strip or redact the offending thinking blocks from the transcript and retry the request, transparently surfacing a notice to the user
• Graceful degradation: If auto-strip isn't possible, present the user a clear in-channel message explaining the issue and offering /reset without losing the transcript (e.g. auto-write a session synthesis first)
• Preventive: Strip thinking/redacted_thinking blocks from assistant messages before persisting them to the session JSONL, since Anthropic's API doesn't allow them to survive across cache boundaries anyway

Actual Behavior

• Session silently bricks — user receives error messages in Telegram
• Gateway logs show the error clearly but no user-facing recovery path is offered
• User must manually /reset, losing all session context with no warning

Environment

• OpenClaw version: gateway.log shows claude-sonnet-4-6 model
• Channel: Telegram direct
• Session duration when bricked: ~18 hours (large, rich session)
• Thinking mode: adaptive

Logs

From gateway.err.log:

[agent/embedded] embedded run failover decision: decision=surface_error reason=format
rawError=400 {"type":"error","error":{"type":"invalid_request_error",
"message":"messages.1.content.12: thinking or redacted_thinking blocks in the latest 
assistant message cannot be modified. These blocks must remain as they were in the original response."}}

Impact

High. Long-running sessions with adaptive reasoning are the highest-value sessions — they accumulate the most context. A cache miss (common after any system prompt file change) permanently destroys them with no warning.

Suggested Fix

In the session file repair path, add a special case for this error class: strip all thinking and redacted_thinking blocks from the most recent assistant message(s) and retry. The thinking content is non-recoverable after a cache miss anyway — removing it preserves the text response while allowing the session to continue.

Filed from OpenClaw Telegram session on behalf of user. Diagnosed via gateway logs.