OpenAI Codex OAuth in 2026.3.13 does not honor env proxy during code-to-token exchange #51569
Description
Bug type
Regression (worked before, now fails)
Summary
On macOS, OpenClaw 2026.3.13 completes the browser auth step for OpenAI Codex OAuth but fails at code-to-token exchange, while 2026.2.6-3 succeeds under the same proxy setup.
Steps to reproduce
- On macOS, set
HTTP_PROXYandHTTPS_PROXYto a local HTTP proxy. - Run
[email protected]. - Start OpenAI Codex OAuth onboarding.
- Complete the browser sign-in successfully.
- Observe OpenClaw fail at the token exchange step with
unsupported_country_region_territory. - Downgrade to
[email protected]and repeat the same flow. - Observe the OAuth flow complete successfully.
Expected behavior
Under the same proxy setup, the OpenAI Codex OAuth flow should complete in 2026.3.13, as observed in 2026.2.6-3.
Actual behavior
The browser auth step succeeds, but OpenClaw 2026.3.13 fails during code-to-token exchange with:
[openai-codex] code->token failed: 403 {"error":{"code":"unsupported_country_region_territory","message":"Country, region, or territory not supported","param":null,"type":"request_forbidden"}}
OpenAI OAuth failed
Error: Token exchange failed
### OpenClaw version
2026.3.13 (failing), 2026.2.6-3 (last known good)
### Operating system
macOS 26.3.2
### Install method
npm global
### Model
openai-codex/gpt-5.4
### Provider / routing chain
openclaw -> local HTTP proxy via HTTP_PROXY/HTTPS_PROXY -> auth.openai.com OAuth token exchange
### Additional provider/model setup details
The failing flow uses OpenAI Codex OAuth in `[email protected]`.
Observed code path:
- `[email protected]` imports `loginOpenAICodex` from `@mariozechner/pi-ai/oauth`
- `[email protected]` `dist/oauth.js` re-exports `./utils/oauth/index.js`
- new `dist/utils/oauth/index.js` no longer imports `../http-proxy.js`
- `dist/utils/oauth/openai-codex.js` still uses plain `fetch(TOKEN_URL, ...)`
Observed older working path:
- `[email protected]` imports `loginOpenAICodex` from `@mariozechner/pi-ai`
- old `pi-ai` OAuth entry imported `../http-proxy.js`
- that proxy init called `setGlobalDispatcher(new EnvHttpProxyAgent())
### Logs, screenshots, and evidence
```shell
Observed failure in `2026.3.13`:
[openai-codex] code->token failed: 403 {"error":{"code":"unsupported_country_region_territory","message":"Country, region, or territory not supported","param":null,"type":"request_forbidden"}}
OpenAI OAuth failed
Error: Token exchange failed
Observed success in 2026.2.6-3 under the same local proxy workflow.
Observed code comparison:
old @mariozechner/pi-ai OAuth entry imported ../http-proxy.js
new @mariozechner/pi-ai/oauth path does not import that proxy init
openai-codex.js remained on plain fetch(...)
Observed runtime verification on the old path:
before=Agent
after=EnvHttpProxyAgent
Observed runtime verification after local patching of 2026.3.13 to import a proxy init shim before the OpenAI OAuth flow:
before=Agent
after=EnvHttpProxyAgent
Impact and severity
Affected users/systems/channels: macOS users using OpenAI Codex OAuth behind env-based local proxies
Severity: High (blocks OpenAI Codex onboarding)
Frequency: Observed consistently in 2026.3.13 and resolved after downgrade to 2026.2.6-3
Consequence: OpenAI Codex OAuth cannot complete, so onboarding is blocked
Additional information
Last known good version: 2026.2.6-3
Observed bad version: 2026.3.13
Observed local workaround:
import a proxy-init shim before the OpenAI OAuth flow so the global undici dispatcher becomes EnvHttpProxyAgent.
This looks like a regression caused by the move from @mariozechner/pi-ai to @mariozechner/pi-ai/oauth without preserving the previous proxy-init side effect.