Skip to content

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

Merged
obviyus merged 1 commit into
openclaw:mainfrom
Nanako0129:fix/codex-ws-http-fallback
Mar 29, 2026
Merged

fix: keep openai-codex on HTTP responses transport#55535
obviyus merged 1 commit into
openclaw:mainfrom
Nanako0129:fix/codex-ws-http-fallback

Conversation

@Nanako0129

@Nanako0129 Nanako0129 commented Mar 27, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

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

  • Bug fix
  • New feature
  • Breaking change
  • Refactor
  • Docs
  • Test-only

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

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.

@openclaw-barnacle openclaw-barnacle Bot added agents Agent runtime and tooling size: XS labels Mar 27, 2026
@greptile-apps

greptile-apps Bot commented Mar 27, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This is a focused, narrowly-scoped bug fix that prevents openai-codex / openai-codex-responses from entering the generic OpenAI websocket transport path. The root cause was that PR #53702 inadvertently made the shouldUseOpenAIWebSocketTransport selector websocket-eligible for Codex, even though Codex normalizes to the ChatGPT backend HTTP path rather than the public OpenAI Responses websocket endpoint — causing websocket failures followed by HTTP fallback in production smoke testing.

  • attempt.thread-helpers.ts: Simplifies shouldUseOpenAIWebSocketTransport to a single strict equality check (provider === "openai" && modelApi === "openai-responses"), with a clear comment explaining why openai-codex is excluded until a verified provider-specific websocket target exists.
  • attempt.spawn-workspace.websocket.test.ts: Removes the now-incorrect "accepts the Codex responses transport pair" test case and adds the openai-codex / openai-codex-responses pair as an explicit rejection case within the mismatched-pairs test.

Confidence Score: 5/5

Safe to merge — the change is a one-line logic fix that restores the correct HTTP-only path for openai-codex and is backed by an explicit regression test.

The implementation is correct, minimal, and well-commented. The test file is updated to both remove the now-incorrect acceptance case and add an explicit rejection assertion. No other callsites or transitive behaviour are affected. No risks beyond the acknowledged follow-up if Codex later gets a websocket target, which is low-risk since the existing HTTP path continues to work.

No files require special attention.

Important Files Changed
Filename Overview
src/agents/pi-embedded-runner/run/attempt.thread-helpers.ts Simplifies shouldUseOpenAIWebSocketTransport to exclude openai-codex, keeping it on the HTTP responses path with an explanatory comment.
src/agents/pi-embedded-runner/run/attempt.spawn-workspace.websocket.test.ts Removes the now-incorrect codex acceptance test and adds an explicit rejection assertion for the openai-codex/openai-codex-responses pair.

Reviews (1): Last reviewed commit: "fix: keep openai-codex on HTTP responses..." | Re-trigger Greptile

@Nanako0129

Nanako0129 commented Mar 27, 2026

Copy link
Copy Markdown
Contributor Author

I checked the current CI summary and the failures do not appear to point at the two files changed in this PR. The red jobs look dominated by unrelated upstream drift / flaky shards (for example Mattermost type-check, plugin-sdk/config drift, and existing contract/time-out failures), but I’m happy to adjust if maintainers see a direct regression here.

@Nanako0129

Nanako0129 commented Mar 29, 2026

Copy link
Copy Markdown
Contributor Author

Follow-up validation: this is now reproducible in my production install as well, not just in the isolated smoke environment that motivated the PR.

After updating to OpenClaw 2026.3.28, the gateway journal shows the same fallback pattern on openai-codex/gpt-5.4:

[agent/embedded] [ws-stream] WebSocket connect failed for session=50b208c8-8b8d-4430-981d-879328b8d1ec; falling back to HTTP. error=Error: Unexpected server response: 500

Observed twice in the same session:

  • 2026-03-29 16:53:43 +08:00
  • 2026-03-29 16:53:47 +08:00

The request still completes after HTTP fallback, but this confirms the current generic websocket path mismatch is not limited to a local smoke-only setup.

@Nanako0129
Nanako0129 force-pushed the fix/codex-ws-http-fallback branch from 0a5fbd7 to 24bfe52 Compare March 29, 2026 09:08
@obviyus obviyus self-assigned this Mar 29, 2026
@obviyus
obviyus force-pushed the fix/codex-ws-http-fallback branch from 24bfe52 to d170050 Compare March 29, 2026 09:30
@obviyus
obviyus merged commit 571da81 into openclaw:main Mar 29, 2026
8 checks passed
obviyus
obviyus approved these changes Mar 29, 2026
View reviewed changes

@obviyus obviyus left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed latest changes. Research confirmed OpenClaw's openai-codex path is ChatGPT-backed HTTP, while both OpenAI docs and ~/Developer/codex websocket support are API-key/OpenAI-provider based, not ChatGPT-OAuth websocket reuse. Keeping codex on HTTP here is the correct fix until a real codex-specific WS target/auth path is proven.

@obviyus

obviyus commented Mar 29, 2026

Copy link
Copy Markdown
Contributor

Landed on main.

Thanks @Nanako0129.

@obviyus obviyus mentioned this pull request Mar 29, 2026
Closed
This was referenced Apr 10, 2026
Closed
Merged
@steipete steipete mentioned this pull request Apr 25, 2026
Closed
@clawsweeper clawsweeper Bot mentioned this pull request Apr 30, 2026
Closed
@clawsweeper clawsweeper Bot mentioned this pull request May 12, 2026
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@obviyus obviyus obviyus approved these changes

Assignees

@obviyus obviyus

Labels

agents Agent runtime and tooling size: XS

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@Nanako0129 @obviyus