[Bug]: Existing Codex CLI thread bypasses pool over direct WebSocket while status reports opencodex-local (2.53.0) #4550

Client or integration

Codex CLI

Area

Proxy and routing

Summary

An existing Codex CLI thread repeatedly hits the native ChatGPT usage limit while OpenCodex 2.53.0 reports routing=opencodex-local and its two-account pool has a working secondary account. Thread-correlated Codex diagnostics establish that the failing requests connect directly to wss://chatgpt.com/backend-api/codex/responses, bypassing the pool.

This initially looked like quota/affinity failover, but the failing thread's actual destination changes the diagnosis. Please investigate the active-client routing/configuration lifecycle and whether status can distinguish configured routing from the route retained by a running client.

Reproduction

Observed sequence; not yet a deterministic clean-start reproduction:

1. Use Codex CLI 0.154.0 with ChatGPT login and an existing long-running thread using gpt-6-astra.
2. Have OpenCodex 2.53.0 running locally with the canonical OpenAI provider in pool mode, two Plus accounts, quota strategy, and auto-switch threshold 95.
3. The primary account reaches its quota while the secondary has substantial quota remaining. Manual secondary selection successfully serves other proxied requests.
4. Run ocx status: live proxy health succeeds and routing is reported as opencodex-local.
5. Continue the existing CLI thread. It repeatedly returns usage_limit_exceeded instead of reaching the pool.
6. Correlate the thread's Codex SQLite diagnostics and session completion events: the Responses WebSocket destination is the direct ChatGPT endpoint. There is no corresponding proxy usage record for these turns.

Expected: the client uses the configured proxy route, or the integration clearly identifies that an existing client must be restarted/resumed to adopt it. A configured-route status should not be mistaken for proof that an active client is routed.

Actual: repeated direct upstream requests exhaust the native credential while a healthy local pool is available.

Version

OpenCodex 2.53.0, Codex CLI 0.154.0. The latest upstream release checked at reporting time is v2.53.0.

Operating system

Linux / WSL2

Provider and model

OpenAI ChatGPT login, gpt-6-astra, low reasoning effort.

Logs or error output

Sanitized extraction, with thread IDs, request IDs, account labels, headers, and credentials omitted:

2026-09-13 19:07:50 UTC
  target: codex_api::endpoint::responses_websocket
  destination: wss://chatgpt.com/backend-api/codex/responses
2026-09-13 19:07:51 UTC
  same thread task_complete.error.codex_error_info: usage_limit_exceeded

2026-09-13 19:08:41 UTC
  target: codex_api::endpoint::responses_websocket
  destination: wss://chatgpt.com/backend-api/codex/responses
2026-09-13 19:08:43 UTC
  same thread task_complete.error.codex_error_info: usage_limit_exceeded

CLI: You've hit your usage limit.

ocx status, checked during investigation:
  Proxy: running
  Health: http://127.0.0.1:10100/healthz ok (live)
  routing=opencodex-local, service=installed-but-unhealthy, shim=absent

The service warning is real: the systemd unit is inactive, but a separate live 2.53.0 proxy process answers health checks and serves other traffic. Restarting the proxy previously did not resolve the affected CLI thread.

The affected CLI process was associated with the exact session via its open rollout file. Its environment has no OPENAI_BASE_URL or CODEX_HOME override, and its command line has no base_url/model_provider override. No raw diagnostics are attached because they can contain sensitive headers.

Redacted configuration

Current root keys, verified by parsing the TOML:

openai_base_url = "http://127.0.0.1:10100/v1"
experimental_realtime_ws_base_url = "http://127.0.0.1:10100/v1"

No explicit root model_provider. Relevant OpenCodex settings:

{
  "autoSwitchThreshold": 95,
  "multiAgentMode": "v1",
  "providers": {
    "openai": {
      "authMode": "forward",
      "codexAccountMode": "pool"
    }
  }
}

accountPoolStrategy is omitted and defaults to quota in 2.53.0. pool.cacheAffinity is omitted. A secondary account is manually pinned; its identifier is intentionally omitted.

Scope and remaining uncertainty

• Direct routing of the failed turns is confirmed. This report does not establish a defect in pool priority selection or quota failover.
• The current config is confirmed, but its exact contents when the affected process started are not established. Retained pre-injection configuration is a possible explanation. A fresh-process reproduction remains necessary before claiming Codex 0.154.0 ignores openai_base_url.
• Other proxied requests and manual secondary success do not prove this thread was proxied.
• Earlier 429 usage records belong to other requests and are deliberately excluded as evidence for this thread.
• The observed direct upstream error's wire representation is not established by the task-completion error alone.
• Related closed issue: [Bug]: ocx status reports the proxy healthy while routing is native, so nothing actually routes #2411 concerned an absent override and missing routing status. Here the override exists and status explicitly says opencodex-local, while the active client's actual destination is direct.

Checks

• I searched existing issues and documentation/source relevant to routing.
• I removed secrets, tokens, account details, request credentials, and personal data.