Summary

A channel-bound conversation stopped receiving replies even though the gateway and channel provider were healthy. 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 message.

Environment

• OpenClaw: 2026.5.18 (50a2481)
• @openclaw/codex: 2026.5.12
• Provider/model: openai-codex/gpt-5.5
• Surface: channel/forum-thread style ingress -> embedded/pi Codex harness
• Runtime: Linux, Node 22.x

Evidence Pattern

Operational identifiers, channel ids, session ids, host names, and deployment paths are intentionally redacted.

Two messages entered the gateway for the same bound conversation. Both embedded runs failed before a reply:

[telegram] Inbound message <redacted bound conversation>
[openai-transport] [responses] error ... status=400 code=invalid_encrypted_content ...
The encrypted content <redacted> 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 historical assistant content blocks like:

{ "type": "thinking", "thinkingSignature": "{...\"encrypted_content\":\"<redacted>\"...}" }

Those blocks were being included in mirrored replay context for later turns. After removing these thinking blocks from the local transcript and clearing the associated Codex app-server binding, the same conversation was able to run again and return a normal 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 non-response.

Actual Behavior

• Channel 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.
• The user received no response or actionable error.

Local Operational Workaround Applied

On the affected deployment, the conversation was restored by:

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

A local installed-runtime mitigation was also applied 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 channel UX because failure is invisible to the user. A non-sensitive channel-visible fallback/error would have made the incident much easier to diagnose.