openclaw - ✅(Solved) Fix [Bug]: Telegram handler drops thinking block signatures on multi-turn conversations, causing Anthropic API rejection [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#69579Fetched 2026-04-22 07:50:34
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Participants
Timeline (top)
labeled ×2

Multi-turn Telegram conversations with claude-opus-4-7 (extended thinking enabled) fail on turn 2+ with "messages.1.content.0: Invalid signature in thinking block" because OpenClaw's Telegram handler does not preserve signed thinking blocks when rebuilding the messages array for follow-up turns.

Error Message

Telegram error shown to user: "LLM request rejected: messages.1.content.0: Invalid signature in thinking block"

Root Cause

Multi-turn Telegram conversations with claude-opus-4-7 (extended thinking enabled) fail on turn 2+ with "messages.1.content.0: Invalid signature in thinking block" because OpenClaw's Telegram handler does not preserve signed thinking blocks when rebuilding the messages array for follow-up turns.

Fix Action

Fix / Workaround

Affected: All OpenClaw users with Telegram integration using any model with extended thinking enabled. Severity: High (blocks all multi-turn Telegram conversations). Frequency: Always (100% reproducible on turn 2+). Consequence: Silent failure from user's perspective — turn 1 displays normally, turn 2+ never gets a response. Users either disable extended thinking entirely or implement proxy-side workarounds.

Current workaround: stripping thinking blocks from inbound messages at the local proxy layer before forwarding to Anthropic. Trade-off: loses extended-thinking chain across multi-turn Telegram conversations. Single-turn cron-scheduled tasks (not multi-turn) are unaffected by both the bug and the workaround.

PR fix notes

PR #70437: fix(agents): preserve Anthropic thinking signatures on replay (#69579)

Description (problem / solution / changelog)

Summary

  • Problem: Multi-turn requests that replay assistant thinking blocks (extended thinking) failed with Invalid signature in thinking block because the transport layer ran sanitizeTransportPayloadText on stored thinking bytes, which can change character encoding (e.g. lone surrogates) and invalidates Anthropic’s cryptographic signature.
  • Why it matters: Any channel (e.g. Telegram) that keeps conversation history and replays the prior turn’s assistant content hits this on turn 2+; the failure can look like a “silent” second reply.
  • What changed: When a stored thinking block is signed, replay thinking verbatim; resolve signature via shared resolveAnthropicStoredThinkingSignature from thinkingSignature (if non-empty after trim) or signature. Use the same helper in transformTransportMessages and convertAnthropicMessages. Add regression tests (lone-surrogate, signature-only) plus a small unit test for the resolver (including thinkingSignature: "" falling back to signature).
  • What did NOT change (scope boundary): No Telegram-specific code paths; no API contract or gateway protocol change; no CHANGELOG entry in this PR.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #69579
  • Related
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: convertAnthropicMessages in src/agents/anthropic-transport-stream.ts always sanitized block.thinking in one branch; for signed thinking, bytes must match the server-issued signature exactly. Sanitization changed those bytes. The transform layer needed the same “has signature” resolution for both thinkingSignature and signature.
  • Missing detection / guardrail: No unit test asserting that stored signed thinking is not passed through sanitizeTransportPayloadText, and no shared resolver between transform and stream paths.
  • Contributing context (if known): Reported on Telegram + Opus extended thinking; the bug is in shared Anthropic transport, not Telegram.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/agents/anthropic-transport-stream.test.ts, src/agents/anthropic-stored-thinking-signature.test.ts
  • Scenario the test should lock in: A stored thinking block with a valid signature and a lone UTF-16 surrogate in thinking is emitted to the request payload with thinking unchanged; same for blocks that only store signature (no thinkingSignature).

User-visible / Behavior Changes

Multi-turn conversations with Anthropic models using extended thinking and prior assistant thinking blocks in history should no longer fail at the API with Invalid signature in thinking block when the prior turn’s thinking was stored with a signature.

Diagram (if applicable)

N/A

Security Impact (required)

  • New permissions/capabilities? No
  • Exposes or persists new secrets? No
  • Network surface change? No

Testing

  • pnpm test src/agents/anthropic-transport-stream.test.ts src/agents/anthropic-stored-thinking-signature.test.ts

Changed files

  • src/agents/anthropic-stored-thinking-signature.test.ts (added, +29/-0)
  • src/agents/anthropic-stored-thinking-signature.ts (added, +21/-0)
  • src/agents/anthropic-transport-stream.test.ts (modified, +84/-0)
  • src/agents/anthropic-transport-stream.ts (modified, +8/-4)
  • src/agents/transport-message-transform.ts (modified, +3/-1)

Code Example

Telegram error shown to user: "LLM request rejected: messages.1.content.0: Invalid signature in thinking block"

Reproducible every time a follow-up message is sent in a Telegram conversation where turn 1 used extended thinking.
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Multi-turn Telegram conversations with claude-opus-4-7 (extended thinking enabled) fail on turn 2+ with "messages.1.content.0: Invalid signature in thinking block" because OpenClaw's Telegram handler does not preserve signed thinking blocks when rebuilding the messages array for follow-up turns.

Steps to reproduce

  1. Configure OpenClaw with Telegram integration and claude-opus-4-7 as primary model, extended thinking enabled.
  2. Send a message via Telegram that is routed to Opus (any message triggering Opus routing keywords).
  3. Receive Opus's reply in Telegram (turn 1 succeeds, thinking block signature issued by Anthropic).
  4. Send a follow-up message in the same conversation.
  5. Anthropic rejects the request: "LLM request rejected: messages.1.content.0: Invalid signature in thinking block."
  6. From the user's perspective, turn 2 silently fails — no reply appears in Telegram.

Expected behavior

OpenClaw's Telegram handler should preserve signed thinking blocks byte-for-byte when rebuilding the messages array for follow-up turns. Anthropic's API requires signed thinking blocks from prior assistant turns to be returned unchanged; any modification invalidates the signature.

Actual behavior

Turn 1 succeeds and the reply posts to Telegram normally. On turn 2, Anthropic returns "messages.1.content.0: Invalid signature in thinking block" and the request is rejected before reaching the model. No reply posts to Telegram. User sees silent failure — first message worked, follow-ups do not.

OpenClaw version

2026.4.15 (041266a)

Operating system

macOS (Mac mini)

Install method

npm global

Model

anthropic/claude-opus-4-7 with extended thinking enabled

Provider / routing chain

openclaw -> local proxy (byte-for-byte passthrough, localhost:3099) -> anthropic

Additional provider/model setup details

Local proxy at localhost:3099 was independently audited and confirmed to be a byte-for-byte passthrough with no content-block manipulation. Thinking block signatures round-trip cleanly through the proxy itself. The signature loss must be happening inside OpenClaw's Telegram handler's message reconstruction logic, which is in the compiled runtime and not user-editable.

Logs, screenshots, and evidence

Telegram error shown to user: "LLM request rejected: messages.1.content.0: Invalid signature in thinking block"

Reproducible every time a follow-up message is sent in a Telegram conversation where turn 1 used extended thinking.

Impact and severity

Affected: All OpenClaw users with Telegram integration using any model with extended thinking enabled. Severity: High (blocks all multi-turn Telegram conversations). Frequency: Always (100% reproducible on turn 2+). Consequence: Silent failure from user's perspective — turn 1 displays normally, turn 2+ never gets a response. Users either disable extended thinking entirely or implement proxy-side workarounds.

Additional information

Current workaround: stripping thinking blocks from inbound messages at the local proxy layer before forwarding to Anthropic. Trade-off: loses extended-thinking chain across multi-turn Telegram conversations. Single-turn cron-scheduled tasks (not multi-turn) are unaffected by both the bug and the workaround.

Root cause hypothesis: OpenClaw's Telegram handler rebuilds messages[] for turn 2 using stored history. The thinking block from turn 1's response is either (a) not being preserved byte-for-byte, (b) being reconstructed from plain text with signature stripped, or (c) being reordered in the content array. Any of these would invalidate the signature. The compiled runtime is not user-editable so precise location cannot be confirmed without OpenClaw source access.

extent analysis

TL;DR

The most likely fix is to modify OpenClaw's Telegram handler to preserve signed thinking blocks byte-for-byte when rebuilding the messages array for follow-up turns.

Guidance

  • Verify that the issue is indeed caused by the Telegram handler's message reconstruction logic by checking the messages array for any modifications or reordering of the thinking block.
  • Check the OpenClaw documentation for any configuration options or updates that may address this issue, as the compiled runtime is not user-editable.
  • Consider implementing a temporary workaround by modifying the local proxy layer to preserve the thinking block signature, similar to the current workaround of stripping thinking blocks.
  • Investigate the possibility of updating or patching the OpenClaw Telegram handler to fix the issue, if the root cause is confirmed to be within the handler's logic.

Example

No code snippet is provided as the issue is related to the compiled runtime of OpenClaw's Telegram handler, which is not user-editable.

Notes

The root cause of the issue is hypothesized to be within OpenClaw's Telegram handler, but the precise location cannot be confirmed without access to the OpenClaw source code. The current workaround of stripping thinking blocks at the local proxy layer may not be ideal, as it loses the extended-thinking chain across multi-turn conversations.

Recommendation

Apply a workaround by modifying the local proxy layer to preserve the thinking block signature, as this is the most feasible solution given the current constraints. This workaround may have trade-offs, such as losing the extended-thinking chain, but it can help mitigate the issue until a more permanent fix is available.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

OpenClaw's Telegram handler should preserve signed thinking blocks byte-for-byte when rebuilding the messages array for follow-up turns. Anthropic's API requires signed thinking blocks from prior assistant turns to be returned unchanged; any modification invalidates the signature.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING