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

[Elvin-yk]

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/token returns:
  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:7890
  • https_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

1. Start the third-party CLI's ChatGPT OAuth flow.
2. Browser opens auth.openai.com/oauth/authorize?...
3. Sign-in completes.
4. Browser reaches localhost callback and shows:
   Authentication successful. Return to your terminal to continue.
5. The CLI then exchanges the authorization code for tokens.
6. /oauth/token returns 403 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:

1. the official Codex login path is using a materially different transport/network path than a generic OAuth client
2. some ChatGPT OAuth clients are not expected to work unless they satisfy additional requirements
3. unsupported_country_region_territory is 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.

[Elvin-yk]

Closing this because the issue was resolved locally and does not currently look like a Codex service-side bug.

What I confirmed on 2026-03-10:

• official codex-cli was already working
• the failing third-party CLI was running its OAuth token exchange under Node 22 fetch() without actually honoring my proxy routing
• once I forced that process to use an undici EnvHttpProxyAgent, the OAuth token exchange succeeded
• I also had to ensure the local auth directory was writable so the resulting auth profile could be saved

So the discrepancy came from the third-party client's runtime/network behavior on my machine, not from official Codex auth behavior.

Closing to avoid leaving the wrong impression upstream.