Summary

On OpenClaw 2026.6.1, a native/OpenClaw-runtime openai-chatgpt-responses session can succeed on the first turn and then fail on the next turn with a provider-side 400 invalid_encrypted_content before any model output.

The user-visible error is sanitized to:

LLM request failed: provider rejected the request schema or tool payload.

The raw trajectory error is:

Codex error: {"type":"error","error":{"type":"invalid_request_error","code":"invalid_encrypted_content","message":"The encrypted content gAAA... could not be verified. Reason: Encrypted content could not be decrypted or parsed."},"status":400}

Environment

• OpenClaw: 2026.6.1 (2e08f0f)
• macOS: 26.4.1 arm64
• Node: 25.9.0
• Runtime / harness: OpenClaw native (agentRuntime.id = "openclaw")
• Provider/model shape:

{
  "provider": "openai",
  "model": "gpt-5.5",
  "api": "openai-chatgpt-responses",
  "baseUrl": "https://chatgpt.com/backend-api/codex",
  "agentRuntime": { "id": "openclaw" },
  "params": { "thinking": "xhigh", "transport": "sse" }
}

Reproduction observed

1. Start a fresh session using openai/gpt-5.5 with api=openai-chatgpt-responses and native runtime.
2. Send a first turn that causes a normal model response and tool use. This succeeds.
3. The successful assistant turn stores a thinking block with thinkingSignature containing a serialized Responses reasoning item with encrypted_content.
4. Send a second turn in the same session.
5. OpenClaw replays the prior assistant reasoning item in the submitted history.
6. The ChatGPT/Codex backend rejects the request before model output with 400 invalid_encrypted_content.

This explains why the previous turn succeeds but the next turn fails.

What I found in dist

openai-chatgpt-responses requests encrypted reasoning:

// openai-chatgpt-responses-*.js
include: ["reasoning.encrypted_content"]

sanitizeSessionHistory only drops reasoning history when the provider replay policy says so:

const droppedReasoning = policy.dropReasoningFromHistory
  ? dropReasoningFromHistory(validatedThinkingSignatures)
  : validatedThinkingSignatures;

But buildOpenAIReplayPolicy(ctx) currently treats openai-chatgpt-responses as a Responses-family API with synthetic tool results, and does not set dropReasoningFromHistory for this API.

Local mitigation that fixed it

Adding this to buildOpenAIReplayPolicy(ctx) fixed the same session immediately:

...ctx.modelApi === "openai-chatgpt-responses" ? { dropReasoningFromHistory: true } : {},

After restarting the gateway, the same session and same message completed successfully. The submitted history no longer contained thinkingSignature; only the old failed assistant turn's plain-text errorMessage still contained the string invalid_encrypted_content, which is harmless.

Expected behavior

For openai-chatgpt-responses against the ChatGPT/Codex backend, OpenClaw should not replay stale/unverifiable encrypted reasoning content, or should retry safely without it before surfacing an error.

Actual behavior

The next turn replays encrypted reasoning content and the backend rejects the whole request with 400 invalid_encrypted_content, resulting in an empty/non-deliverable assistant turn.

Related

• Related to fix(openai-codex): omit encrypted reasoning replay for native responses #87151 (openai-codex native Responses encrypted reasoning replay)
• Related to fix: retry stale Responses reasoning replay safely #88917 (stale Responses reasoning replay retry)
• Related to openai-codex provider: multi-turn sessions permanently break with 400 invalid_encrypted_content after an OAuth token refresh #84511 (closed, OAuth refresh variant)
• Also observed while testing the native/Pi route discussed in Pi/native runtime routes openai-chatgpt-responses to boundary-aware transport and fails on ChatGPT Codex endpoint #90086, but this issue is specifically about encrypted reasoning replay.