Codex Request Timed Out? 7 Fixes That Actually Work (2026)

Quick Answer

"Request timed out" in Codex is almost never an OpenAI outage — it is a network-path problem. The most common causes, in order, are: a missing terminal proxy, the macOS sandbox silently blocking network access, MCP servers that exceed their startup timeout, and DNS/SNI blocking on restricted networks. The single most reliable fix in 2026 is to point Codex at a stable, globally reachable endpoint like TeamoRouter, which eliminates DNS pollution, proxy conflicts, and endpoint throttling in one step. Below are seven fixes that actually work, ranked from simplest to most thorough.

Why Codex Requests Time Out

Codex CLI sends every request to https://api.openai.com/v1/responses by default. When that request stalls, you see one of a handful of error strings:

These share one trait: the browser on the same machine often works fine while the terminal does not. That asymmetry is the key diagnostic clue — the browser reads system proxy settings, but most CLI tools do not. Fix the terminal's network path and you fix the timeout.

How to Diagnose Which Layer Is Failing

Before trying fixes blindly, run a 60-second diagnosis to locate the failing layer. The answer tells you which fix applies:

If the curl test returns a fast 401, your network path to OpenAI is healthy and the timeout is coming from a sandbox, MCP, auth, or shell-initialization layer. If curl hangs, the problem is DNS, proxy, or SNI — jump to the network fixes.

Fix 1: Configure the Terminal Proxy

If your browser reaches OpenAI but Codex times out, the terminal is almost certainly bypassing your proxy. Codex only honors these environment variables — it does not read system proxy settings, PAC files, or WPAD auto-discovery:

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:7890"
export NO_PROXY="localhost,127.0.0.1"

Add these to ~/.zshrc (macOS/Linux) or set them system-wide in Windows, then open a new terminal. Verify the path before blaming Codex:

curl -I --max-time 20 https://api.openai.com/v1/models

A fast 401 response means the proxy path works and you can move on. Anything else means the proxy node itself is the bottleneck.

Fix 2: The macOS Sandbox Is Silently Blocking Network Access

On macOS, setting network_access = true in ~/.codex/config.toml is silently ignored by the seatbelt sandbox, which unconditionally sets CODEX_SANDBOX_NETWORK_DISABLED=1. Outbound calls from sandboxed shell commands then fail with connection timeouts, even though the API itself is reachable.

The fix is to run Codex with full network access at the CLI level:

codex --sandbox danger-full-access "your prompt"

For convenience, add an alias so every session gets network access:

alias codex='CODEX_SANDBOX_NETWORK_DISABLED=0 codex --sandbox danger-full-access'

Note that setting sandbox_mode = "danger-full-access" in config.toml alone is not sufficient — the CLI flag is what actually takes effect. If you run many shell commands inside Codex (builds, tests, git push), this fix alone usually resolves most "request timed out" errors.

Fix 3: Raise the MCP Server Startup Timeout

MCP servers (Context7, Playwright, Dart, Firebase, and similar) frequently produce request timed out on Windows because Codex spawns them directly without going through cmd.exe. Two things go wrong: executables on PATH are not found, and slow first-time startup exceeds the default timeout.

Wrap MCP commands in cmd.exe /c and raise the timeout in ~/.codex/config.toml:

[mcp_servers.context7]
command = "cmd"
args = ["/c", "npx", "-y", "@upstash/context7-mcp", "--api-key", "your-key"]
env = { SystemRoot = "C:\\Windows" }
startup_timeout_ms = 30_000

A startup_timeout_ms of 20,000 to 60,000 ms is reasonable — first npx invocation downloads the package and can easily blow past the default. If a remote MCP server keeps timing out, install mcp-remote globally (npm install -g mcp-remote) and point the server at a remote URL instead.

Fix 4: Forward Your Proxy Through SSH (Remote Hosts)

When Codex runs on a remote machine through VSCode Remote SSH, it uses the remote host's network. If that host cannot reach api.openai.com, requests time out even though your local machine is fine.

Forward your local proxy to the remote box in ~/.ssh/config:

Host myserver
    RemoteForward 10808 127.0.0.1:10808

Then export the proxy on the remote host:

export HTTPS_PROXY=http://127.0.0.1:10808
export HTTP_PROXY=http://127.0.0.1:10808

Verify from the remote host with curl -I --max-time 20 -x http://127.0.0.1:10808 https://api.openai.com/v1/models — a quick 401 confirms the tunnel works. Also set http.proxy / https.proxy in VSCode's Remote Settings (JSON) so editor-integrated calls use the same path.

Fix 5: Expired or Revoked Authentication

A mid-stream request timed out (rather than one at startup) is sometimes an authentication problem in disguise. Codex 0.41-era releases had a known issue where expired or revoked refresh tokens caused streaming timeouts. If a timeout appears consistently after a few minutes of use, and your network path is clean, refresh the session:

codex logout
codex login

If you authenticate with an API Key instead of ChatGPT login, confirm the key is valid and has balance — a revoked key can surface as a hang before the actual 401 is reported.

Fix 6: Fix DNS and SNI Blocking on Restricted Networks

If you are in a region with a restricted internet connection, the failure chain is usually deeper than a proxy issue:

1. DNS pollution — api.openai.com resolves to a spoofed or dead IP.
2. SNI blocking — the TLS handshake probe triggers a connection reset even with correct DNS.
3. IP range throttling — OpenAI's server ranges are rate-limited or blocked during peak hours.

A VPN or proxy helps only if the whole traffic path is covered, which is why "the browser works but Codex doesn't" is so common. When you cannot reliably control DNS and SNI per process, the robust fix is to change the endpoint Codex talks to. A gateway like TeamoRouter hosts an OpenAI-compatible endpoint on domains that are not blocked, so DNS pollution and SNI interference disappear at the source. Point Codex at it with two environment variables and no proxy at all:

export OPENAI_API_KEY="your-key"
export OPENAI_BASE_URL="https://gateway.teamorouter.com/v1"
codex

Fix 7: Rule Out Sandboxed Shell Command Timeouts

Sometimes the "timeout" is not the API at all — it is a shell command running inside the Codex sandbox that hangs. If you see exit code 124 (GNU timeout) for trivial commands like ls or git status, your shell initialization is the culprit. Known triggers include pyenv versions before 2.6.16, which hang during rehash inside the sandbox.

Fix by updating pyenv, passing a higher timeout_ms to shell tool calls, or running the session with --yolo when you trust the task. If a sandboxed run fails before any OpenAI response exists, treat it as an execution-environment problem, not an API problem.

The Fastest Path: Skip the Firefighting

Individually, these fixes each solve one layer of the stack: proxy, sandbox, MCP, SSH, auth, DNS. But many users hit two or three layers at once — a corporate proxy AND a macOS sandbox AND a flaky VPN node. Troubleshooting them one by one is how an afternoon disappears.

That is why the pragmatic 2026 fix is to remove the fragile layers instead of debugging them. TeamoRouter gives Codex a single OpenAI-compatible endpoint that is directly reachable from most networks, with no proxy required and no sandbox-network gymnastics. The setup is two environment variables:

1. Sign up at TeamoRouter and copy your API Key
2. Set OPENAI_API_KEY and OPENAI_BASE_URL (see the Codex install guide)
3. Run codex — if it was a network-layer timeout, it now works

FAQ

Why does the browser reach OpenAI but Codex CLI times out?

The browser reads system proxy settings (or a VPN extension), while CLI tools ignore system settings entirely and rely on HTTPS_PROXY / HTTP_PROXY environment variables. Set those, or switch Codex to a directly reachable endpoint.

Is "request timed out" caused by OpenAI being down?

Almost never. Timeouts are overwhelmingly network-path issues — proxies, sandboxes, MCP startup, or DNS/SNI interference. OpenAI's API returns structured errors (401, 429, 5xx) when it is reachable; a hang or ETIMEDOUT means the request never completed the round trip.

Does TeamoRouter require a proxy or VPN?

No. TeamoRouter's endpoint is directly reachable from most networks, so you configure the base URL once and remove the proxy layer entirely.

Why does my Codex Desktop App time out but the CLI works?

The Desktop App uses the system network configuration, which is a different path from the terminal's environment variables. Check system proxy settings first, then enter the gateway base URL directly in the app's settings to give both surfaces the same stable path.

Get Started

The simplest fix is switching the endpoint:

1. Sign up for TeamoRouter and get an API Key
2. Set OPENAI_API_KEY and OPENAI_BASE_URL
3. Run curl to verify connectivity — expect a fast non-000 status code, then start codex

Get Your Free Codex Setup →

Access Codex, Claude Code, and Gemini CLI stably through TeamoRouter.