Error messages

error sending request for url

error sending request for url

You'll usually see it inside a longer line, and the URL tells you which part of Codex failed:

stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)

A GitHub search on September 25, 2026 turned up 273 issues in openai/codex quoting it. We read where Codex prints it in the 0.157.0 release and in several older ones, and went through the longest-running thread about it.

Why the line leaves out the actual cause

The words aren't Codex's. They're how reqwest prints a failed request: "error sending request", then "for url" and the address if it has one. The real reason (a DNS lookup that failed, a refused connection, a certificate it rejected) is attached to the error underneath, and that printout never includes it. We found that surprising for the single most useful fact, and it's why people in the threads can't tell a VPN problem from a certificate problem.

It also means the request never got a response. An error with an HTTP status in it (401, 429, 500) did reach the server. This one didn't.

How the wording changed between releases

Up to 0.147.0 every such failure on a model request became a dropped stream, which is where the long form above comes from, and Codex retried it like one. From 0.148.0 a failure to connect is reported separately as Connection failed: error sending request. From 0.156.0 Codex strips the URL out of these errors, so current versions print plain error sending request.

Current versions also wait out an outage. When a turn can't connect, 0.157.0 shows Reconnecting... waiting for network and keeps trying, starting at five seconds and backing off to one attempt a minute. That matters for the oldest report still open, issue #3355 from September 2025, where closing a MacBook's lid mid-task burned through all five retries within seconds.

Sign-in hasn't changed. codex login still prints the URL, as in Token exchange failed: error sending request for url (https://auth.openai.com/oauth/token).

Find out which failure it is

Run codex doctor. It probes your provider's address and sorts the failure into plain categories, among them "TLS handshake or certificate validation failed", "proxy authentication required" and "connect failed". It also flags a certificate variable pointing at a file it can't read. It isn't in every build: a reporter on 0.153.4 found it missing from their bundled CLI.

Proxies and VPNs

"VPN" turns up in 74 of these issues and "proxy" in 124. By default Codex follows the standard HTTPS_PROXY, HTTP_PROXY, ALL_PROXY and NO_PROXY variables. One commenter on #3355 found VS Code launched from the desktop never saw those variables, so its Codex extension failed while the terminal worked; starting VS Code with code . from that terminal fixed it. On Windows, another cleared it by unticking "Use a proxy server for local connections" in the classic network settings.

On macOS, codex doctor warns if a system proxy is set but Codex isn't using it, and points at codex features enable respect_system_proxy. The flag is marked as under development, and the doctor text says to ask your administrator first. Sign-in already retries through the system proxy once when its first connection fails.

Corporate certificates

Networks that inspect encrypted traffic swap in their own root certificate. Codex reads a PEM bundle from CODEX_CA_CERTIFICATE, or from SSL_CERT_FILE if that isn't set. One #3355 commenter behind corporate SSL decryption had an expired company root in WSL, and the error went away once they installed the new one with update-ca-certificates.

IPv6 and WSL

Two September reports trace it to IPv6. In #44990 the Windows desktop app was quietly running Codex inside WSL, where DNS returned only IPv6 addresses the machine couldn't route, so every check the user ran on the Windows side looked healthy. In #45426 a proxy's hostname returned a good IPv4 address and a DNS failure for IPv6, and Codex gave up before connecting while curl got through. If you're on WSL, run getent hosts chatgpt.com inside it and see what comes back.

Several people on home Wi-Fi fixed it by switching to a phone hotspot, which rules the machine out quickly.