Bug type

Runtime / provider routing bug

Summary

openai-codex appears to enter the generic OpenAI websocket transport path on current main, but the websocket connection target is still the generic OpenAI Responses websocket endpoint. In an isolated smoke test on merged upstream/main, this causes the websocket attempt to fail with HTTP 500 and fall back to HTTP transport.

The chat/tool flow still succeeds after fallback, so this is not a total functional failure. The issue is that the openai-codex provider seems to be treated as websocket-eligible without clear evidence that the generic OpenAI websocket endpoint is the correct transport target for the Codex OAuth path.

Steps to reproduce

1. Use current merged upstream/main that includes fix: route codex responses over websocket and suppress gated core tool warnings #53702.
2. Configure an isolated OpenClaw home with openai-codex available via OAuth auth state.
3. Start a local gateway from the built source tree.
4. Send an agent turn using openai-codex/gpt-5.4.
5. Observe gateway logs during the request.

Expected behavior

Either:

• openai-codex should use a websocket transport that is valid for the Codex OAuth path, or
• openai-codex should stay on its HTTP path if no valid websocket transport exists for that provider path.

It should not attempt a websocket connection that immediately fails and falls back on every request.

Actual behavior

In the isolated smoke test, the request succeeds, but the gateway logs show:

[agent/embedded] [ws-stream] WebSocket connect failed ... falling back to HTTP. error=Error: Unexpected server response: 500

This indicates that openai-codex was routed into websocket transport first, but the connection failed and the request completed only after HTTP fallback.

OpenClaw version

Current merged upstream/main after #53702.
Exact tested tree included merge commit:
d72cc7a380e53710c9e38f147584da88ccda06fe

Operating system

Linux

Install method

Built from source from current upstream/main

Model

openai-codex/gpt-5.4

Provider / routing chain

Provider:
openai-codex

API:
openai-codex-responses

Observed transport behavior:
websocket attempted first, then fallback to HTTP after websocket failure

Additional provider/model setup details

Observed source behavior on current main:

• openai-codex provider normalizes to ChatGPT backend HTTP base URL:
  • https://chatgpt.com/backend-api
• websocket eligibility now includes:
  • provider === "openai-codex"
  • modelApi === "openai-codex-responses"
• websocket connection manager still uses the generic OpenAI Responses websocket URL:
  • wss://api.openai.com/v1/responses

Relevant files from current main:

• extensions/openai/openai-codex-provider.ts
• src/agents/pi-embedded-runner/run/attempt.thread-helpers.ts
• src/agents/openai-ws-connection.ts
• src/agents/openai-ws-stream.ts

Logs, screenshots, and evidence

Observed gateway log from isolated smoke environment:

[agent/embedded] [ws-stream] WebSocket connect failed ... falling back to HTTP. error=Error: Unexpected server response: 500

Additional observed evidence from current source:

• openai-codex is normalized to ChatGPT backend HTTP path
• websocket manager target remains the generic OpenAI websocket URL
• the request still succeeds after HTTP fallback

I also checked my long-running production environment logs and did not find the same websocket fallback message there, so this issue is currently reproduced only in the isolated smoke environment on merged main.

Impact and severity

Medium

The request still completes because HTTP fallback works, so this is not a hard outage. However, it suggests a transport mismatch for openai-codex and may add unnecessary websocket failures, noisy transport behavior, or hidden instability on that provider path.

Additional information

This report is intentionally limited to observed evidence.

What is confirmed:

• openai-codex is websocket-eligible on current main
• websocket manager still targets the generic OpenAI Responses websocket URL
• isolated smoke test shows websocket failure with HTTP fallback
• chat/tool flows still succeed after fallback

What is not yet confirmed:

• whether openai-codex is supposed to use a provider-specific websocket endpoint
• whether openai-codex should remain HTTP-only instead

Functional note:
I verified that basic chat, multi-turn context retention, markdown file edits, and an exec->write chain still worked in the same isolated smoke environment after fallback to HTTP.