Official codex-cli login works, but another ChatGPT OAuth client using auth.openai.com succeeds at authorize/callback and then gets 403 unsupported_country_region_territory on /oauth/token
Summary
I can log in successfully with official codex-cli, but a separate CLI that uses ChatGPT OAuth against auth.openai.com fails in a surprising way:
- browser authorize succeeds
- localhost callback succeeds
- token exchange at
https://auth.openai.com/oauth/tokenreturns:
403 unsupported_country_region_territory
Because official codex-cli works on the same host, with the same account and same proxy/network, I am filing this here to ask whether this discrepancy is expected or whether there are undocumented requirements around client/scopes/transport for ChatGPT OAuth.
Environment
- Date observed: 2026-03-10
- codex-cli:
0.112.0 - OpenClaw (the third-party CLI exhibiting the failure):
2026.3.8 - Node on the third-party CLI host:
v22.12.0 - OS: Linux
- Terminal proxy env on that host:
http_proxy=http://127.0.0.1:7890https_proxy=http://127.0.0.1:7890- Clash runtime was also verified on a US exit:
- IP
23.132.124.130 Los Angeles, California, US
What succeeds
Official codex-cli login/use works in this environment.
What fails
A third-party CLI's OpenAI Codex OAuth flow uses these endpoints:
- authorize:
https://auth.openai.com/oauth/authorize - token exchange:
https://auth.openai.com/oauth/token - redirect URI:
http://localhost:1455/auth/callback
The browser flow succeeds and reaches localhost successfully, but the token exchange returns:
403 {"error":{"code":"unsupported_country_region_territory","message":"Country, region, or territory not supported","param":null,"type":"request_forbidden"}}
Reproduction outline
- Start the third-party CLI's ChatGPT OAuth flow.
- Browser opens
auth.openai.com/oauth/authorize?... - Sign-in completes.
- Browser reaches localhost callback and shows:
Authentication successful. Return to your terminal to continue.
- The CLI then exchanges the authorization code for tokens.
/oauth/tokenreturns403 unsupported_country_region_territory.
Why I am asking here
The same account and environment can use official codex-cli, so this does not look like a plain account-wide or machine-wide block.
This suggests at least one of the following:
- the official Codex login path is using a materially different transport/network path than a generic OAuth client
- some ChatGPT OAuth clients are not expected to work unless they satisfy additional requirements
unsupported_country_region_territoryis being returned in cases that are not purely geographic from the end user's point of view
Request
Could you clarify whether third-party ChatGPT OAuth clients hitting auth.openai.com/oauth/authorize and /oauth/token are expected to work in this scenario?
If not, documentation on the expected constraints would help.
If yes, it would be useful to know what difference between official codex-cli and another OAuth client could cause authorize + callback to succeed but /oauth/token to return unsupported_country_region_territory on the same machine/account.
Related context
The third-party project also has an issue open on their side because their implementation may not be consistently respecting proxy routing during token exchange.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗