ChatGPT authentication fails with global proxy enabled - Codex
Quick fix
Upgrade cc-switch to v3.16.4+ and enter a working proxy address under 「设置 → 路由 → 全局出站代理」, then retry Codex/ChatGPT authentication.
Symptom
Section titled “Symptom”ChatGPT无法认证, 全局代理已经开了ChatGPT authentication fails even though the global proxy is enabled
In older versions of cc-switch, the Codex/ChatGPT OAuth flow used a hard-coded HTTP client that ignored the app’s 「全局出站代理」 setting and only honored terminal environment variables. As a result, cc-switch worked when launched from a terminal with proxy environment variables, but authentication failed when launched by double-clicking it. The maintainer confirmed this was fixed in v3.16.4 (#4583): the authentication flow now uses the shared proxy client and follows the global proxy setting. Another common prerequisite is that the proxy itself must be working and its exit IP region must be allowed by OpenAI (Hong Kong is a typical example); check the exit IP with iplark.com or a similar service first.
The same cluster includes two related variants with different root causes: #4991 reported that after upgrading to 3.16.5 and switching back to OpenAI Official, requests still seemed to be hijacked by cc-switch, Codex slowed down, and token usage became abnormal. That issue is open/stale, and the thread contains no confirmed fix. #7217 reported that, under Codex desktop 26.905 / codex v0.153.x, requests bypassed `http://127.0.0.1:15721/v1` and connected directly to `api.openai.com`. The maintainer judged that if `~/.codex/config.toml` already contains `model_provider = "custom"` and the CLI works, the more likely cause is that the Codex desktop app forces its built-in OpenAI provider while logged in and ignores the upstream restriction in config.toml, rather than an issue cc-switch can fix on its own.
First confirm that the proxy node works and its exit region is allowed by OpenAI: visit iplark.com to check the exit IP. An unsupported region such as Hong Kong can cause ChatGPT/Codex authentication to fail even when the proxy’s “global mode” is enabled.
Do not rely only on the proxy service’s “global/rule” mode or terminal environment variables. Enter the local proxy listening address, such as `127.0.0.1:7890`, under 「设置 → 路由 → 全局出站代理」 in cc-switch.
Upgrade cc-switch to v3.16.4 or later. This version fixes the issue where Codex/ChatGPT OAuth ignored the app’s global outbound proxy and only honored environment variables. Retry authentication after upgrading.
If you use Codex local routing mode, check whether `~/.codex/config.toml` contains `model_provider = "custom"` and whether the custom provider points to `http://127.0.0.1:15721/v1`. Then run the `codex` CLI directly in a terminal and check whether the cc-switch request log shows an incoming request.
~/.codex/config.toml model_provider = "custom"[model_providers.custom]base_url = "http://127.0.0.1:15721/v1"experimental_bearer_token = "PROXY_MANAGED"If the CLI uses local routing but the Codex desktop app still connects directly to the official service, the maintainer’s assessment in #7217 is that this is an upstream limitation: while logged in, the desktop app forces its built-in OpenAI provider. Use the CLI to verify the configuration and follow the original issue for the desktop app problem. If you are stuck on the login page, edit that provider card in cc-switch, change `requires_openai_auth` to `false`, and save it (edit the card, not only the live file).
~/.codex/config.toml [model_providers.custom]requires_openai_auth = falseFor #4991’s report that switching back to official still routes through a proxy or cannot exit it, with abnormal token usage, the thread provides no confirmed fix or one-click reset. Do not perform unverified cleanup; back up the configuration first, then follow up on the original issue with the cc-switch version, Codex version, and request logs.
Affected Versions
Section titled “Affected Versions”Source Issues
Section titled “Source Issues”This page is distilled from 3 real issues
- My proxy service is already in “global” mode. Why does Codex authentication in cc-switch still not use the proxy?
- The proxy service’s “global/rule/direct” mode is not the same as cc-switch’s 「设置 → 路由 → 全局出站代理」 setting. Older cc-switch OAuth flows also ignored the in-app proxy and only honored environment variables. Upgrade to v3.16.4+ and explicitly configure the global outbound proxy.
- The proxy works in my browser. Why doesn’t it work in cc-switch?
- In #3984, the user reported that cc-switch worked when launched from a terminal with proxy environment variables configured. This indicates that the browser/terminal had a proxy, but the app’s OAuth client did not use one. This was the hard-coded HTTP client issue fixed in v3.16.4.
- How can I tell whether the proxy is not working or the node’s region is unsupported?
- Visit iplark.com to check the exit IP, then confirm that OpenAI allows the exit region. The thread specifically mentions Hong Kong as a typical unsupported region.
- The Codex desktop app does not use 127.0.0.1:15721, but the CLI works. Is cc-switch broken?
- According to the maintainer’s reply in #7217, if `model_provider = "custom"` is present and the CLI can use local routing, the more likely cause is that the Codex desktop app forces its built-in OpenAI provider while logged in and ignores the upstream restriction in config.toml. cc-switch cannot change this on its own.
- What should I do if switching back to OpenAI Official still seems hijacked and token usage is abnormal?
- #4991 is open/stale. The thread contains only the user’s report (such as 291 requests in 1 minute and heavy token usage), with no confirmed fix. This page cannot provide a verified one-click way to disable it; follow up on the original issue and back up the configuration first.
Related problems
Section titled “Related problems”This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.