openclaw - 💡(How to fix) Fix Bug: Context truncation breaks interleaved thinking block signatures, poisoning session permanently

Summary

When a session using Anthropic extended thinking exceeds the model's actual context window limit, OpenClaw's context truncation algorithm drops messages without respecting interleaved-thinking-2025-05-14 constraints. This orphans thinking block signatures, causing Anthropic's API to permanently reject all subsequent messages in that session with Invalid signature in thinking block.

Environment

• OpenClaw 2026.5.26 (10ad3aa)
• Model: anthropic/claude-sonnet-4-6 (200k context limit)
• Channel: Microsoft Teams group chat
• Thinking level: medium (budget_tokens: 8192)
• Session size at failure: ~207k tokens / 840KB JSONL, 146 assistant turns, 139 tool results, 50 thinking blocks

Steps to reproduce

1. Configure an agent with thinkingDefault at any non-off level on claude-sonnet-4-6 (200k context)
2. Run a long multi-turn tool-heavy session (competitive research, data analysis, etc.)
3. Let the session grow past ~200k tokens — OpenClaw's default contextTokens is 1049k so compaction never fires
4. Send a new message once the session is over the model's API limit

Error

LLM request rejected: messages.9.content.133: Invalid signature in thinking block

Every subsequent message fails with the same error. The session is permanently broken.

Root cause

Two problems compound:

1. Thinking-unaware truncation

limitHistoryTurns truncates context by dropping older messages to fit under the model's context window. It does not respect interleaved-thinking-2025-05-14 constraints, which require that:

• Thinking blocks stay paired with their associated tool calls
• Thinking blocks are never orphaned from the tool results that follow them

When truncation drops a tool result but keeps the thinking block that preceded the tool call, Anthropic receives a thinking block whose paired context no longer exists. The signature validation fails.

Relevant code: dist/provider-stream-DRIaVJMo.js and dist/selection-DZnXuqgh.js → limitHistoryTurns

2. One-shot recovery has a bypass

wrapAnthropicStreamWithRecovery catches the Invalid signature error and retries once with thinking blocks stripped. However, if yieldedChunk === true (any streaming output arrived before the error), recovery is skipped entirely to avoid duplicate chunks. This means the session JSONL is never repaired, and the same error fires on every subsequent request.

Relevant code: dist/selection-DZnXuqgh.js → wrapAnthropicStreamWithRecovery, pumpStreamWithRecovery

Proposed fix

Option A — Atomic truncation for thinking turns (preferred)

When truncating context for sessions using interleaved-thinking-2025-05-14, treat each thinking+tool_call+tool_result group as an atomic unit. Never split a thinking block from its paired tool result. If truncation would break a group, drop the entire group or strip the thinking block signature and downgrade to text.

Option B — Signature invalidation on truncation

When limitHistoryTurns removes any message adjacent to a thinking block, strip the thinkingSignature from that thinking block before building the API request. OpenClaw already handles unsigned thinking blocks gracefully (downgrades to text) — this would ensure the truncation never sends an orphaned signed block.

Option C — maxActiveTranscriptBytes as default safeguard

Set a default compaction.maxActiveTranscriptBytes (e.g., "500kb") so long sessions compact before approaching model API limits. This is a partial mitigation, not a root fix.

Impact

• Permanent session failure — no recovery without archiving/resetting the session
• Affects any long multi-turn tool-heavy session with extended thinking on any model with a context window smaller than OpenClaw's 1049k default
• Particularly affects Teams group chat sessions which accumulate context over hours
• The built-in recovery fires but is bypassed in the streaming case, leaving no automatic escape

Workaround

Archive the broken session JSONL manually. OpenClaw creates a fresh session on the next message.