With the pinned Codex 0.144.5, QM passes OPENAI_BASE_URL to the app-server child, but a real accepted turn does not route its Responses WebSocket through that endpoint. Writing the same endpoint as top-level openai_base_url in the isolated CODEX_HOME/config.toml does route it correctly.
I reproduced this three times using the real CodexAppServer and adapter thread/start / turn/start shapes inside a network namespace with all non-loopback egress blocked. The endpoint was a synthetic loopback fake Responses API and the API key was synthetic.
Observed behavior:
- environment-only
OPENAI_BASE_URL: turn/start accepted; no request reached the fake server within 10 seconds
- top-level
openai_base_url: turn/start accepted; fake server received GET /v1/responses with a WebSocket upgrade
This confirms the behavior for Codex 0.144.5 only; I did not have 0.144.4 available locally. A /models probe would not be sufficient because Codex uses the Responses API.
With the pinned Codex 0.144.5, QM passes
OPENAI_BASE_URLto the app-server child, but a real accepted turn does not route its Responses WebSocket through that endpoint. Writing the same endpoint as top-levelopenai_base_urlin the isolatedCODEX_HOME/config.tomldoes route it correctly.I reproduced this three times using the real
CodexAppServerand adapterthread/start/turn/startshapes inside a network namespace with all non-loopback egress blocked. The endpoint was a synthetic loopback fake Responses API and the API key was synthetic.Observed behavior:
OPENAI_BASE_URL:turn/startaccepted; no request reached the fake server within 10 secondsopenai_base_url:turn/startaccepted; fake server receivedGET /v1/responseswith a WebSocket upgradeThis confirms the behavior for Codex 0.144.5 only; I did not have 0.144.4 available locally. A
/modelsprobe would not be sufficient because Codex uses the Responses API.