Summary

On OpenClaw 2026.6.1, an OpenAI OAuth-backed ChatGPT/Codex provider configured for the Pi/native runtime (agentRuntime.id = openclaw, i.e. the pi alias) is routed to the new boundary-aware unified OpenAI transport instead of the existing ChatGPT Codex stream.

That unified path fails against https://chatgpt.com/backend-api/codex/responses with a provider response that looks like HTTP 200 but has an empty content-type and a raw/normalized Connection error.. The agent then fails with FailoverError: LLM request failed: network connection error.

Environment

• OpenClaw: 2026.6.1 (openclaw --version reported OpenClaw 2026.6.1 (2e08f0f))
• OS: macOS 26.4.1 arm64
• Node: 25.9.0
• Provider auth: OpenAI OAuth profile (openai:<redacted-email>)
• Model provider: openai
• Runtime: Pi/native (agentRuntime.id = openclaw; pi normalizes to openclaw)

Redacted config shape

{
  "models": {
    "providers": {
      "openai": {
        "api": "openai-chatgpt-responses",
        "baseUrl": "https://chatgpt.com/backend-api/codex",
        "agentRuntime": { "id": "openclaw" },
        "request": { "allowPrivateNetwork": true }
      }
    }
  },
  "agents": {
    "defaults": {
      "model": { "primary": "openai/gpt-5.5", "fallbacks": [] },
      "models": {
        "openai/gpt-5.5": {
          "agentRuntime": { "id": "openclaw" },
          "params": { "thinking": "xhigh", "transport": "sse" }
        }
      }
    }
  }
}

Reproduction

With the above shape and an OpenAI OAuth profile:

openclaw agent --agent main --session-key agent:main:repro --message 'Reply with exactly OK.' --timeout 180

Actual behavior without local patch

The run fails:

GatewayClientRequestError: FailoverError: LLM request failed: network connection error.

Trajectory shows the run being routed to the boundary-aware unified path:

context.compiled: streamStrategy=boundary-aware:openai-chatgpt-responses transport=sse
model.completed: stopReason=error errorMessage="Connection error." usage=input=0/output=0
session.ended: status=error terminalError=non_deliverable_terminal_turn

Local debug of the same native path showed the internal transport alias and invalid response framing:

[openai-transport] [responses] start provider=openai api=openclaw-openai-responses-transport model=gpt-5.5 baseUrl=https://chatgpt.com/backend-api/codex
[provider-transport-fetch] response status=200 contentType=
[openai-transport] [responses] error causeName=ProviderHttpError causeCode=invalid_provider_content_type message=Connection error.

Expected behavior

For openai + openai-chatgpt-responses + ChatGPT Codex baseUrl + OpenAI OAuth + Pi/native runtime, the embedded agent should use the existing ChatGPT Codex native stream strategy (observed as openclaw-native-codex-responses) or otherwise send/parse the ChatGPT Codex endpoint with the correct protocol/headers.

Evidence that this is a transport regression

Using the same OAuth profile, same baseUrl, same model config, and same network/TUN setup, forcing the embedded agent back to the old ChatGPT Codex stream succeeds:

context.compiled: streamStrategy=openclaw-native-codex-responses transport=sse
model.completed: stopReason=stop errorMessage=None
assistant output: OK

Both main and system-architect smoke tests returned OK after the workaround.

Local workaround used

A local dist workaround was needed to prevent the ChatGPT Codex provider from being captured by the unified boundary-aware transport:

1. Skip provider stream registration for model.provider === "openai" && model.api === "openai-chatgpt-responses".
2. Force resolveOpenClawNativeCodexResponsesStreamFn(...) to return streamSimple for openai-chatgpt-responses.
3. Prevent createOpenAIAttributionHeadersWrapper(...) from swapping the ChatGPT stream into createOpenAIResponsesTransportStreamFn().

This workaround is intentionally narrow to openai-chatgpt-responses; ordinary OpenAI API-key openai-responses, Anthropic, and Codex app-server runtime paths are not the target.

Why this looks like an upstream bug

There appears to already be a special openclaw-native-codex-responses path for this provider/API combination, but in 2026.6.1 the provider stream / OpenAI wrapper / boundary-aware selection path wins first and sends the request through openclaw-openai-responses-transport, which does not currently handle the ChatGPT Codex endpoint response correctly.