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.

openclaw - ✅(Solved) Fix [Bug]: openai-codex enters the generic OpenAI websocket path and falls back to HTTP [1 pull requests, 5 comments, 3 participants]

openclaw2026-03-27 03:19:38

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#55523•Fetched 2026-04-08 01:38:32

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Participants

Timeline (top)

commented ×5cross-referenced ×2closed ×1locked ×1

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.

Error Message

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

Root Cause

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.

Fix Action

Fixed

Fixed by PR: fix: keep openai-codex on HTTP responses transport (https://github.com/openclaw/openclaw/pull/55535)

PR fix notes

PR #55535: fix: keep openai-codex on HTTP responses transport

Repository: openclaw/openclaw
Author: Nanako0129
State: open | merged: False
Link: https://github.com/openclaw/openclaw/pull/55535

Description (problem / solution / changelog)

Summary

keep openai-codex on its existing HTTP responses path instead of routing it into the generic OpenAI websocket transport selector
update the websocket transport selector test to explicitly reject the openai-codex / openai-codex-responses pair

Change Type

Scope

This PR is intentionally narrow.

It only changes websocket transport eligibility for openai-codex on the embedded runner path.

It does not change:

the openai-codex provider normalization logic
HTTP request payload behavior for Codex
any image/media-understanding routing
any memory provider routing

Linked Issue/PR

Related #55523
Follow-up to merged PR #53702
This PR fixes a bug or regression

Root Cause / Regression History

openai-codex models normalize to the ChatGPT backend HTTP path (https://chatgpt.com/backend-api) and use openai-codex-responses.

After #53702, the embedded runner's websocket eligibility selector also treated the openai-codex / openai-codex-responses pair as websocket-eligible. However, the websocket connection manager still targets the generic OpenAI Responses websocket endpoint rather than a Codex-specific transport target.

In isolated upstream-main smoke testing, that caused openai-codex requests to attempt websocket first, fail with HTTP 500, and then fall back to HTTP.

This patch keeps openai-codex on the existing HTTP path until there is a verified provider-specific websocket target and end-to-end support for it.

Behavior Changes

Before:

openai-codex / openai-codex-responses entered the generic OpenAI websocket selector
websocket could fail and fall back to HTTP in isolated smoke tests

After:

only native openai / openai-responses is websocket-eligible
openai-codex stays on HTTP responses transport

Regression Test Plan

Updated:

src/agents/pi-embedded-runner/run/attempt.spawn-workspace.websocket.test.ts

Coverage:

accepts the native openai / openai-responses websocket pair
rejects openai-codex / openai-codex-responses
rejects mismatched provider/API websocket pairs

Repro + Verification

Observed on merged upstream/main during isolated smoke validation of #53702:

openai-codex/gpt-5.4 requests succeeded, but only after websocket failed and the runner fell back to HTTP
gateway log showed websocket connect failure with HTTP 500 before fallback

With this patch:

the websocket selector no longer routes openai-codex into the generic OpenAI websocket path
focused websocket selector test passes locally

Tests

Passed locally:

corepack pnpm test -- src/agents/pi-embedded-runner/run/attempt.spawn-workspace.websocket.test.ts --reporter=verbose
pre-commit pnpm check passed during commit

Risks and Mitigations

Risk:

if openai-codex later gets a valid provider-specific websocket endpoint, this patch will keep it on HTTP until that support is added explicitly

Mitigation:

this preserves the existing working HTTP transport and avoids the currently observed websocket->HTTP fallback path
the selector remains a small, centralized surface to expand later once Codex websocket support is verified end-to-end

AI assistance

AI-assisted: drafted and implemented with Codex, then locally reviewed and tested by me.

Changed files

src/agents/pi-embedded-runner/run/attempt.spawn-workspace.websocket.test.ts (modified, +6/-9)
src/agents/pi-embedded-runner/run/attempt.thread-helpers.ts (modified, +4/-4)

Code Example

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

RAW_BUFFERClick to expand / collapse

Bug type

Runtime / provider routing bug

Summary

Steps to reproduce

Use current merged upstream/main that includes #53702.
Configure an isolated OpenClaw home with openai-codex available via OAuth auth state.
Start a local gateway from the built source tree.
Send an agent turn using openai-codex/gpt-5.4.
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

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.

extent analysis

Fix Plan

To resolve the issue, we need to update the websocket connection manager to use the correct websocket endpoint for the openai-codex provider.

Here are the steps:

Update the openai-ws-connection.ts file to include a conditional statement that checks the provider and model API.
If the provider is openai-codex and the model API is openai-codex-responses, use the ChatGPT backend websocket URL instead of the generic OpenAI Responses websocket URL.

Example code:

// openai-ws-connection.ts
if (provider === 'openai-codex' && modelApi === 'openai-codex-responses') {
  const websocketUrl = 'wss://chatgpt.com/backend-api/ws';
} else {
  const websocketUrl = 'wss://api.openai.com/v1/responses';
}

Update the openai-codex-provider.ts file to include the correct websocket endpoint in the provider configuration.

// openai-codex-provider.ts
const providerConfig = {
  // ...
  websocketEndpoint: 'wss://chatgpt.com/backend-api/ws',
};

Verification

To verify that the fix worked, run the isolated smoke test again and check the gateway logs for the websocket connection attempt. The logs should no longer show a websocket failure with HTTP fallback.

Extra Tips

Make sure to update the relevant files and test the changes thoroughly to avoid any regressions.
Consider adding additional logging or monitoring to detect any future issues with the websocket connection.
Review the OpenAI API documentation to ensure that the ChatGPT backend websocket URL is the correct endpoint for the openai-codex provider.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

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.

#api #parallel task #integration issue #index setup #retrieval issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix [Bug]: openai-codex enters the generic OpenAI websocket path and falls back to HTTP [1 pull requests, 5 comments, 3 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Fix Action

Fixed

PR fix notes

PR #55535: fix: keep openai-codex on HTTP responses transport

Description (problem / solution / changelog)

Summary

Change Type

Scope

Linked Issue/PR

Root Cause / Regression History

Behavior Changes

Regression Test Plan

Repro + Verification

Tests

Risks and Mitigations

AI assistance

Changed files

Code Example

Bug type

Summary

Steps to reproduce

Expected behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Additional provider/model setup details

Logs, screenshots, and evidence

Impact and severity

Additional information

extent analysis

Fix Plan

Verification

Extra Tips

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING