API proxy sidecar returns 404 for Codex CLI /responses endpoint

[lpcox]

Problem

The Smoke Codex workflow fails because the Codex CLI (v1.2.14, model gpt-5.3-codex) now uses the OpenAI Responses API (/responses endpoint) instead of the legacy /v1/chat/completions endpoint. The AWF API proxy sidecar (containers/api-proxy/server.js) does not handle this path, returning a 404 Not Found.

Error from CI logs

ERROR: unexpected status 404 Not Found: Unknown error,
  url: http://172.30.0.30:10000/responses,
  cf-ray: 9ee6133eda2c6ccf-IAD,
  request id: 0b23c169-0f4d-41e6-ae0c-1312e5b144e9

Codex first tries WebSocket connections to ws://172.30.0.30:10000/responses, which fail with reconnection attempts (5/5 twice), then falls back to HTTP POST to the same path and gets 404.

Affected workflow

• Smoke Codex on PR [Deps] Safe patch/minor devDependency refresh (2026-04-17) + Node minimum alignment #2075: run 24610775080

Root cause

The API proxy sidecar (containers/api-proxy/server.js) currently proxies requests to OpenAI at port 10000, but only handles known paths (likely /v1/*). The Codex CLI now sends requests to /responses (the OpenAI Responses API), which the proxy does not recognize and returns 404.

Additionally, Codex attempts WebSocket upgrades to /responses, which the proxy does not support at all.

Proposed solution

Update containers/api-proxy/server.js to:

1. Proxy /responses HTTP requests to api.openai.com/responses on port 10000 (OpenAI), injecting the API key as with existing paths
2. Support WebSocket upgrade for /responses on port 10000, proxying WebSocket connections to wss://api.openai.com/responses with the API key injected in headers
3. Consider a catch-all proxy approach for the OpenAI port (10000) that forwards any path to api.openai.com with auth injection, rather than whitelisting specific paths — this would prevent future breakage when OpenAI adds new API endpoints

Additional context

• Codex CLI logs show auth_header_attached=false and auth_env_openai_api_key_present=false — confirming the proxy is expected to inject credentials
• The WebSocket transport is responses_websocket and the HTTP transport is responses_http
• This is blocking the Smoke Codex workflow on all PRs

[github-actions]

👋 Hello! I noticed this issue might be related to an existing issue:

• [awf] API Proxy: codex engine fails with 401 Unauthorized on OpenAI API #2064 — [awf] API Proxy: codex engine fails with 401 Unauthorized on OpenAI API — also describes the API proxy sidecar failing for Codex CLI when using the /responses endpoint (v1/responses), with key phrases matching: api proxy, codex, openai, responses endpoint, sidecar.

Both issues appear to describe the same root cause: the AWF API proxy sidecar not properly handling the OpenAI Responses API (/responses) for Codex CLI. The difference is the HTTP status code (401 vs 404), which may reflect different stages of the same underlying problem or a regression.

If #2064 already covers your concern, please consider closing this issue as a duplicate or linking them. Otherwise, feel free to clarify how your issue differs (e.g., a new regression after a fix attempt)!

This is an automated message from the issue duplication detector.

Generated by Issue Duplication Detector for issue #2079 · ● 92.7K · ◷