Understand how the Codex app reaches the network
When the OpenAI Codex desktop app cannot sign in, load a workspace, or keep an AI task running, it is tempting to treat the problem as a single “proxy failure.” In practice, a desktop coding app can make several kinds of connections: the app may load account pages in an embedded browser, exchange requests with OpenAI services, retrieve project or workspace data, and start local processes that run tools. Those connections do not necessarily use the same networking interface. A working browser tab is useful evidence, but it does not prove that every request from Codex follows the same route.
Clash can influence traffic in more than one way. System proxy mode makes supported applications use a local HTTP or SOCKS listener. TUN mode captures traffic at the network layer, which can cover applications that ignore the operating system’s proxy setting, although it also introduces adapter, DNS, permission, and routing considerations. Some applications or subprocesses honor proxy environment variables; others use their own networking stack. Do not assume that setting one proxy variable, enabling one switch, or seeing a connected status guarantees that all Codex traffic has been handled.
Start with a simple question: is Codex itself unable to reach its account or service, or does a tool launched from a Codex project fail? A sign-in window that spins points toward the app’s own connection path or authentication flow. An app that opens normally but reports an error when a coding task runs may instead be affected by a child process, a project-specific tool, or a separate endpoint. Keep these cases separate while troubleshooting; changing several proxy layers at once makes it much harder to identify the cause.
Also distinguish local project work from cloud access. Reading files on your computer, applying an edit, or running a local test may work without a remote connection. Signing in, retrieving account information, or using a hosted model requires network access. A local command can fail for reasons unrelated to Clash, such as missing dependencies, filesystem permissions, or a project configuration problem. Record the exact action that fails and the complete error text before changing routing.
Prepare Clash for a clean, controlled test
Before altering rules, confirm that Clash is actually running and that its active profile is the one you intend to test. In Clash Verge, Clash Verge Rev, or another Mihomo-based client, check the profile name, core status, current mode, and available proxy groups. A dashboard that remains open does not necessarily mean the core is healthy or the active configuration has loaded successfully. If the client reports a configuration error, fix that first; otherwise the behavior you observe may not correspond to the rules you think are active.
Next, check whether another network tool is competing for control. A second Clash instance, a corporate VPN, a browser-only proxy extension, a system PAC setting, or an old VPN adapter can create a split route. For a baseline test, avoid changing multiple tools at once. If your computer is managed by an employer or school, do not disable a required security agent or VPN to experiment; ask the administrator which proxy mode is supported.
Confirm the local listener and the operating-system setting separately. If you want to test system proxy mode, enable the system proxy option in the Clash client and verify that the OS proxy settings point to the local address and port shown by that client. Do not copy a port from an old tutorial: HTTP, SOCKS, and mixed ports can be different, and client defaults can change. The indicator in the Clash window and the actual operating-system proxy entry are two separate facts worth checking.
For a first test, prefer the least complicated mode that covers your intended application. If Codex is a conventional desktop app and the system proxy is supported, begin with system proxy mode. If it appears to ignore that setting, or if the app’s helper processes use direct connections, consider testing TUN mode only if your client and operating system support it. TUN may require administrator approval or a network-extension permission. Read the permission prompt carefully and use the client’s documented controls rather than manually adding unknown routes.
Choose one known-good node from a selector group instead of switching repeatedly between servers. A low latency number from a URL test is not a guarantee that every OpenAI service will work through that node: the probe measures its own target and method, not Codex authentication, long-lived requests, or every service endpoint. For diagnosis, consistency matters more than chasing the smallest displayed number. Keep the node fixed until you have completed one test cycle.
If you use a rules-based profile, check the active mode before editing YAML. In Rule mode, the selected proxy group matters only when a matching rule sends the request to that group. In Global mode, traffic is generally directed through the chosen global policy, subject to the client and profile behavior. In Direct mode, Clash does not send ordinary matching traffic through a proxy group. These modes answer different questions; a rule can be correct but irrelevant if the active mode or selected group does not use it.
Configure routing and verify the route Codex uses
Begin with a reversible test: temporarily choose a known working proxy group or global policy, enable the appropriate system proxy setting, then fully quit and reopen Codex. Restarting matters because an application may read proxy configuration only when it starts, and an already-open sign-in window can retain an older connection state. Do not begin by adding a long list of guessed domains. First establish whether a simple, controlled route change alters the result.
If the app works in a broad proxy test but fails in Rule mode, investigate policy matching. Open the Clash connection or traffic log while reproducing the problem. Look for entries created at the time of the failed sign-in or request, then note the destination host, the selected rule, the policy group, and the final outbound. The key question is not merely whether a connection appears, but whether it was matched to the route you intended. A request that reaches DIRECT may indicate a rule-order issue, a rule that does not match the observed host, or a connection that is outside the capture method being tested.
Do not treat any suggested hostname list as complete or permanent. Desktop applications can change service endpoints, use regional infrastructure, or load authentication components from a different host than the one used for model requests. If the log shows a destination, make a narrow, documented rule for the observed need and place it before broad catch-all rules that could capture it first. Avoid routing every domain containing a vendor name through one group unless you understand the side effects; unrelated sites can share names, and overly broad matches make later diagnosis less clear.
After changing a rule, reproduce one action and inspect the log again. Confirm that the newly observed connection selected the expected policy group and that the group selected the node you meant to use. If the connection is absent, do not immediately conclude that the app made no request. System proxy mode may not capture it, the request may use a different process, or a failed action may stop before opening a network connection. In that case, testing TUN mode can help distinguish a proxy-aware application from traffic that bypasses the system proxy, but change only that one variable and repeat the same action.
DNS behavior can complicate the picture. A hostname may resolve through the operating system, through Clash’s configured DNS handling, or through an application-specific resolver. If logs show repeated resolution failures, timeouts before a connection is established, or an unexpected destination address, inspect the DNS settings and recent DNS log entries rather than randomly changing every resolver option. Keep the test narrow: note the hostname, the time, the error, and whether the same lookup succeeds in another application under the same network conditions.
Avoid using a successful browser visit as the only test. A browser may have its own proxy extension, cached account session, or separate DNS behavior. Instead, compare a few observations: does the Codex sign-in page open, does the account flow return to the app, does the app remain signed in after a restart, and does a small remote task complete? If the browser succeeds but Codex does not, that contrast is valuable: it suggests the two applications may not share the same proxy path, not that the whole internet connection is healthy in every respect.
Keep a brief test record while troubleshooting. Note the Clash client and core version, active mode, whether system proxy or TUN was enabled, the selected group and node, the action performed in Codex, and the relevant log outcome. Change one setting at a time and restore the original state if the test makes no difference. This simple discipline prevents a common loop: switching nodes, editing rules, clearing application state, and toggling TUN all at once, then having no way to tell which change helped—or whether the issue disappeared for an unrelated reason.
Troubleshoot sign-in failures, timeouts, and inconsistent behavior
If Codex cannot begin sign-in, first confirm basic connectivity and the Clash core status, then test a known route and restart the app. If the sign-in page loads but the flow never returns to Codex, check the app’s logs and Clash connections during the handoff. Authentication can involve more than one request, and a browser component succeeding does not prove that the desktop app completed its callback. Avoid deleting credentials or resetting the app as an opening move; preserve any useful error message and check whether the failure is reproducible after a normal restart.
If sign-in succeeds but a remote task stalls, compare the timing of the task with Clash’s connection log. A short page load and a longer-running model request can behave differently: idle timeouts, unstable links, or a node that handles brief requests but not sustained sessions may produce a task timeout even when the account page is fast. Test the same small task on one stable node before changing routing rules. If the client shows an established connection that repeatedly closes, record the error and timing; do not assume that adding more domain rules will fix a transport interruption.
If some project actions work while others fail, identify whether the failing action is local or remote. A local test runner may need a package registry, Git host, or another service that is unrelated to Codex’s own model connection. Check the command output and the Clash log for that separate destination. If a project tool uses environment variables, review its own documentation and the environment in which it runs; do not assume that the desktop app automatically passes its proxy settings to every child process. Treat credentials and subscription URLs as sensitive, and never paste tokens or full authorization headers into public logs.
If the Clash dashboard shows no relevant connection during an attempted action, verify that you are watching the correct profile and time window, then repeat the test once. A system proxy setting may not capture the app; a child process may not use the proxy; or the request may be blocked before it reaches the network. If the app works only with TUN enabled, note that result and inspect whether DNS and the operating-system route behave as expected. TUN is a useful diagnostic and routing option, not proof that every future connection will be captured correctly.
If results change after a profile update, compare the effective rules and selected groups rather than assuming the node suddenly became unreliable. Rule providers can refresh, rules can be reordered, and a broad match can take precedence over the line you added. Restore a known-good profile if necessary, then reapply one narrow change at a time. When contacting support, provide the client version, operating system, core version, mode, approximate failure time, and sanitized log excerpts. Remove subscription links, account identifiers, access tokens, and private project paths before sharing diagnostics.
Finally, distinguish a network problem from an account, service, or application issue. Check whether Codex reports an explicit authentication or service error, whether the problem persists after returning to a permitted direct connection, and whether the service’s official status information reports an incident. A proxy change cannot repair an expired account session, a service outage, or a local application bug. If your organization requires a specific gateway or blocks third-party proxy tools, follow that policy rather than attempting to work around it.
Browser extensions and one-off proxy settings can be convenient, but they may cover only browser traffic and offer little visibility into a desktop app’s helper processes. A broad system-wide tunnel can capture more traffic, yet it may be harder to audit and can affect unrelated applications. A maintained Clash client gives you a practical middle ground: clear mode controls, selectable policy groups, and connection logs that help you verify what actually happened instead of guessing. If you want to test the Codex workflow with a Clash client, visit the Clash V.CORE download page and choose a build appropriate for your operating system and network policy.