openclaw - 💡(How to fix) Fix OpenAI Responses replay still poisons sessions on GPT-5.5/GPT-5.4 in 2026.4.25 [1 comments, 2 participants]

Summary

OpenClaw 2026.4.25 still appears to have an OpenAI Responses replay/conversation-state bug that can poison long-lived sessions on current GPT reasoning models.

This is related to the older family of issues around:

• #18282
• #19184
• #19582
• fixed variant in PR #18632

…but this repro appears broader than the old orphaned-reasoning-only variant.

Environment

• OpenClaw: 2026.4.25
• Install: npm global
• OS: macOS 26.3 (Apple Silicon)
• Node: v24.14.0
• Models observed:
  • openai/gpt-5.5
  • openai/gpt-5.4
• API paths observed:
  • openai-responses
  • later failure also surfaced while using GPT-5.4 in the same overall bug investigation path

Actual behavior

A session works for some number of turns, then starts failing with:

400 Item 'msg_...' of type 'message' was provided without its required 'reasoning' item: 'rs_...'

Once the session is poisoned, subsequent requests keep failing in the same session.

Important detail

This is not just a simple GPT-5.5 pin/config mistake.

We verified all of the following during the investigation:

• removing the per-session GPT-5.5 override did not explain the whole issue
• resetting the channel created a real new session id, but the new session could still become poisoned again
• the same overall failure family later appeared with GPT-5.4 as well
• gateway restart alone did not resolve the bad session history state

Concrete stored-history evidence

From the poisoned session transcript, there is a stored assistant turn like this:

• timestamp: 2026-04-27T20:21:38.253Z
• assistant content contains:
  • a thinking block with:
    • blank visible thinking: ""
    • thinkingSignature containing rs_...
    • encrypted_content
    • summary: []
  • a final text block NO_REPLY with textSignature containing msg_...

Later failures reference that exact same pair:

400 Item 'msg_08360604ed2eb6d50069efc551cca8819381d62277021947ae' of type 'message' was provided without its required 'reasoning' item: 'rs_08360604ed2eb6d50069efc54feb608193909e9995b4edf8aa'

So the bad replay is not theoretical — the session file contains the pair, and later OpenAI rejects the replayed history.

Why this seems different from the old fixed variant

PR #18632 fixed unconditional dropping of orphaned OpenAI reasoning blocks.

However, after comparing current main (75c03b28e0f82c9c75717157fc0c924f8be0cf0d) to a local 2026.4.25 install, two additional risky behaviors still appear to exist in current upstream source:

1) Commentary assistant text appears to still be replayed into OpenAI input history

Current upstream source:

• src/agents/openai-ws-message-conversion.ts
• function: convertMessagesToInputItems(...)

In the assistant branch, text blocks are still pushed into assistant message input items based on phase logic, but there does not appear to be an explicit suppression of commentary phase during replay into OpenAI input.

That means progress/planning text may be entering canonical assistant history sent back to OpenAI.

2) Reasoning items appear to be dropped if they have no visible summary/content text

Current upstream source:

• src/agents/openai-ws-message-conversion.ts
• function: buildAssistantMessageFromResponse(...)

Current behavior still appears to do:

const reasoning = extractResponseReasoningText(item);
if (!reasoning) continue;

That means a reasoning item with:

• encrypted reasoning content
• empty visible summary
• empty visible content

can be skipped entirely during persistence, even though OpenAI docs explicitly describe encrypted reasoning items as relevant for stateless/manual replay and conversation state.

This looks like a different failure mode than “orphaned reasoning block in old history”:

• the system may be preserving the assistant msg_* side of the turn
• while not preserving a replay-safe form of the paired reasoning item

OpenAI doc alignment

OpenAI docs for Responses/reasoning/conversation state indicate:

• previous_response_id is usually the safest path for preserving prior assistant state
• when replaying manually/statelessly, prior assistant state must be replayed correctly
• encrypted reasoning items exist specifically to support correct stateless reuse of reasoning state

That lines up with this failure class: malformed or incomplete replayed assistant state causes the API to reject the request.

Impact

This can poison long-lived interactive sessions and make them unusable until history is effectively discarded.

Request

Please investigate whether current upstream still has a replay gap for OpenAI Responses around one or both of these cases:

1. commentary assistant text being replayed into canonical assistant history
2. reasoning items with encrypted content but no visible summary/content being dropped during persistence/reconstruction

Helpful places to inspect

• src/agents/openai-ws-message-conversion.ts
  • convertMessagesToInputItems
  • buildAssistantMessageFromResponse
• src/agents/pi-embedded-helpers/openai.ts
• src/agents/openai-ws-stream.ts
• src/agents/openai-transport-stream.ts

If useful, I can provide a sanitized transcript fragment showing the exact stored assistant turn and the later API rejection referencing the same msg_* / rs_* pair.