openclaw - 💡(How to fix) Fix Codex replay can silently fail Telegram turns with invalid_encrypted_content from mirrored thinking blocks

Summary

A Telegram topic stopped receiving replies even though the gateway and Telegram channel were healthy. The inbound messages were accepted, but the embedded Codex run failed before producing a deliverable reply because stale mirrored thinking blocks with thinkingSignature / encrypted_content were replayed back to the Responses API.

This made the user-facing symptom look like OpenClaw simply ignored the Telegram message.

Environment

• OpenClaw: 2026.5.18 (50a2481)
• @openclaw/codex: 2026.5.12
• Provider/model: openai-codex/gpt-5.5
• Surface: Telegram forum topic -> embedded/pi Codex harness
• Gateway host: Linux, Node 22.x

Evidence

Two Telegram messages entered the gateway for the same session/topic:

2026-05-19T00:36:52Z [telegram] Inbound message telegram:group:-1003873045224:topic:29613
2026-05-19T00:39:33Z [telegram] Inbound message telegram:group:-1003873045224:topic:29613

Both embedded runs failed before a reply:

[openai-transport] [responses] error ... status=400 code=invalid_encrypted_content ...
The encrypted content gAAA... could not be verified. Reason: Encrypted content could not be decrypted or parsed.

Embedded agent failed before reply: LLM request failed: provider rejected the request schema or tool payload.

The corresponding trajectory recorded:

terminalError: non_deliverable_terminal_turn
assistantTexts: []
finalStatus: error

The session transcript contained many historical assistant content blocks like:

{ "type": "thinking", "thinkingSignature": "{...\"encrypted_content\":\"gAAAA...\"...}" }

Those blocks were being included in mirrored replay context for later turns. After removing these thinking blocks from the local transcript and clearing the Codex app-server binding, the exact same session was able to run again and return a normal test response.

Expected Behavior

OpenClaw/Codex replay should not send stale provider-encrypted reasoning payloads back to the model when they cannot be verified for the current request/thread/auth context.

At minimum:

• Strip thinking / redacted_thinking / thinkingSignature blocks from mirrored session history before sending replay messages to Responses.
• Treat invalid_encrypted_content as a recoverable replay-sanitization failure: retry once with reasoning blocks removed.
• Surface a clear channel-visible error if no reply can be delivered, instead of silent Telegram non-response.

Actual Behavior

• Telegram ingress accepted the messages.
• Gateway/channel health stayed OK.
• The Codex request failed with 400 invalid_encrypted_content.
• The turn ended as non_deliverable_terminal_turn with no assistant text.
• Telegram user received no response or actionable error.

Local Operational Workaround Applied

On the affected host, I restored the session by:

1. Backing up the affected transcript and trajectory.
2. Removing historical thinking blocks carrying encrypted reasoning signatures from the topic transcript.
3. Clearing the Codex app-server binding for that session.
4. Restarting the gateway.
5. Verifying the same session could produce a normal response again.

I also applied a local hotfix in the installed runtime to strip replayed thinking blocks from mirrored history before building Codex request messages. This is only an operational patch and should be replaced by an upstream fix.

Notes

This may also interact badly with Telegram UX because failure is invisible to the user. A channel-visible fallback/error would have made the incident much easier to diagnose.