Skip to content

Thinking blocks stored without Anthropic signatures cause replay failures ("Invalid signature in thinking block") #91501

Description

@highnoonoffice

Summary

When extended thinking is enabled (any level: high, adaptive, etc.), OpenClaw stores thinking blocks in the session JSONL without their Anthropic-issued signature field. On subsequent turns, those unsigned thinking blocks are replayed to the Anthropic API, which rejects the entire request with:

invalid_request_error: messages.N.content.M: Invalid `signature` in `thinking` block

This makes the channel permanently broken until the session is manually cleared. /new does not fix it because each new session inherits the thinkingLevel setting from the previous one and reproduces the broken state within 2 turns.

Behavior

Version: OpenClaw 2026.6.1
Model: anthropic/claude-sonnet-4-6
Channel: Telegram (also reproducible on any channel with multi-turn sessions)
Thinking level: high (also affects adaptive)

What happens

  1. Extended thinking is enabled (thinkingLevel: high or via /reasoning)
  2. Turn 1: request sent, Anthropic returns thinking blocks with signature fields in the API response
  3. OpenClaw saves thinking blocks to the session .jsonl without the signature field (stripped on write)
  4. Turn 2: request sent with full message history — thinking blocks from Turn 1 are included but have no signature
  5. Anthropic returns invalid_request_error: Invalid signature in thinking block
  6. Channel shows "LLM request failed" to the user
  7. Every subsequent message fails with the same error

Why /new doesn't fix it

Each new session inherits the thinking_level_change event (set to high) from the previous session's JSONL. Within 2 turns the new session is broken again.

Confirmed via log inspection

From /tmp/openclaw/openclaw-2026-06-08.log:

{
  "event": "embedded_run_agent_end",
  "isError": true,
  "error": "LLM request failed: provider rejected the request schema or tool payload.",
  "providerRuntimeFailureKind": "replay_invalid",
  "providerErrorType": "invalid_request_error",
  "providerErrorMessagePreview": "messages.5.content.66: Invalid `signature` in `thinking` block"
}

Direct inspection of the session .jsonl confirms thinking blocks are present with has_sig=False:

# message.content items of type "thinking" — no "signature" key
[0] type=thinking, has_sig=False, thinking="This is a system event indicating..."

The trajectory.jsonl prompt.submitted events also show thinking blocks replayed without signatures.

Expected behavior

One of:

  1. Preserve signatures on write — when saving thinking blocks to the session .jsonl, include the signature field from the Anthropic API response
  2. Strip thinking blocks from replay — when replaying session history, omit thinking blocks that are missing valid signatures rather than sending them and causing a hard failure
  3. Graceful fallback on replay_invalid — when Anthropic returns replay_invalid, automatically strip thinking blocks from the message history and retry the request

Option 1 is the cleanest long-term fix. Option 3 is the best user-facing recovery path.

Workaround

Until fixed, set agents.defaults.thinkingDefault: "off" in openclaw.json and manually remove thinking blocks from the affected session JSONL:

# For each message in the session JSONL:
# - Remove content items where type == "thinking" or "redacted_thinking"
# - Change thinkingLevel events from "high" to "off"

Then restart the gateway.

Impact

  • Extended thinking (any level) is not safely usable on any channel that persists multi-turn session history
  • Telegram users who enable /reasoning will hit a permanent broken state on their primary channel
  • The channel recovers only with manual JSONL surgery or thinking=off

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High-priority user-facing bug, regression, or broken workflow.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions