From ClashX to Clash Verge: Why Web Pages Work but Codex Can't Connect
Recently I switched from ClashX, which I had used for years on my Mac, to Clash Verge. The main reason was that ClashX had been timing out frequently lately. Testing the nodes with other tools showed no issues, so I suspected it was due to lack of maintenance (the project has been unmaintained for a long time). I decided to try something new. Clash Verge is still being updated and uses the Mihomo core.
After the switch, I ran into some network issues. GitHub, YouTube, and chatgpt.com all opened fine in the browser, but Codex couldn’t connect to the internet. Setting proxy environment variables in the command line didn’t work either, though tools like Git worked normally. After some back and forth, with help from ChatGPT, I added the proxy variables to ~/.codex/.env and Codex returned to normal.
Web pages working doesn’t mean Codex can connect
At first, I treated chatgpt.com and Codex as the same network connection, assuming that configuring PROXY for the chatgpt.com domain in the rules would be enough. But it didn’t work; they don’t use the same network path.
When a browser visits chatgpt.com, the request is sent by Chrome or Safari. Browsers typically read the macOS system proxy, so as long as Clash Verge successfully takes over the system proxy, GitHub, YouTube, and ChatGPT web pages can be accessed.
Codex, on the other hand, involves processes running locally and also invokes commands like Git, curl, and npm. Each of these uses its own network library, and a common practice is to read HTTP_PROXY、HTTPS_PROXY and ALL_PROXY. These processes don’t necessarily adopt the macOS system proxy, nor do they automatically get the same network path just because the browser can connect.
| Access method | Who sends the request | Common proxy source |
|---|---|---|
| chatgpt.com | Browser | macOS system proxy |
| Codex session | ChatGPT/Codex local process | Process environment, app network config |
| Codex executed commands | Git, curl, npm subprocesses | Shell or inherited environment variables |
| TUN mode | Virtual NIC takes over traffic | Clash Verge routing rules |
On the same Mac, there is no single proxy state that all programs are forced to share. The browser has its own network processes, connection pools, and cache. Its successful access to GitHub only proves that the path from the browser to Clash Verge is working. Whether Codex can connect depends on what environment the Codex process inherited at startup and whether the tools it invokes recognize those variables.
Environment variables also have a timing gap. After writing to ~/.zshrc, newly opened terminals can read it, but GUI apps launched from Finder won’t re-read the shell configuration. An already running ChatGPT/Codex won’t automatically update its environment either. This is a common reason why web pages keep working while Codex still times out.
Clash Verge’s TUN is currently off. As a result, connections that don’t read the system proxy or environment variables will attempt a direct connection. The browser works as usual while Codex times out; so it’s not contradictory.
The network_access = true in Codex’s configuration is not a proxy switch either. It only determines whether the sandbox allows network access; it doesn’t route requests to Clash Verge.
Previously there was no .env, so why did 7890 work?
The old ClashX proxy port was 7890, with automatic system proxy enabled. While checking shell history, I found I had manually run:
export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890So previously there was no ~/.codex/.env; Codex traffic went through the proxy via environment variables. The system proxy covered browsers and some apps, while the shell environment handled some CLI programs. They happened to point to 7890, making it look like ClashX directly supported Codex proxying.
After switching to Clash Verge, the Mixed Port became 7897. Only 7897 is listening now; neither 7890 nor 7898 has a service. If an old process still holds 7890, or Codex doesn’t pick up the new environment variables, connections will fail.
In ~/.codex/.env add:
HTTP_PROXY=http://127.0.0.1:7897
HTTPS_PROXY=http://127.0.0.1:7897
ALL_PROXY=socks5://127.0.0.1:7897
NO_PROXY=localhost,127.0.0.1,::17897 is the Mixed Port, handling both HTTP and SOCKS5.
If you also want Git, curl, and npm in standalone terminals to use the proxy, set the corresponding lowercase variables in ~/.zshrc. After changing .env or the port, fully quit and reopen ChatGPT/Codex, because already-running GUI processes won’t pick up environment changes automatically.
When testing, first confirm the port:
lsof -nP -iTCP:7897 -sTCP:LISTEN
scutil --proxy
env | rg -i '^(http|https|all|no)_proxy='Then explicitly access the OpenAI API through the proxy:
curl -I --proxy http://127.0.0.1:7897 \
https://api.openai.com/v1/modelsIf it returns 401 Unauthorized, the network and TLS are working; the request just lacks API credentials. Timeouts, connection refused, or DNS failures are the actual network issues.
This issue has nothing to do with Clash Verge’s compatibility. The browser, the Codex local process, and the command-line tools just happen to run on the same Mac; they do not share a unified proxy switch.