›_ Codex Issues
Codex Issues / #16079

Linux + HTTP proxy: Codex CLI fails in both API key mode and device-auth mode, while curl works for Responses API

Open 💬 9 comments Opened Mar 28, 2026 by github-yxb
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.117.0

What subscription do you have?

Organization

Which model were you using?

_No response_

What platform is your computer?

Linux server

What terminal emulator and version are you using (if applicable)?

_No response_

What issue are you seeing?

Codex CLI fails on a Linux server behind an HTTP proxy, even though direct curl works from the same shell session.

I tested all of the following in the same Linux shell:

  1. curl to the OpenAI Responses API works, including streaming:

```bash
curl -N -v https://api.openai.com/v1/responses \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-d '{
"model": "gpt-5.2",
"input": "say hello",
"stream": true
}'

  1. Starting codex in the same shell fails during conversation with:

Stream disconnected before completion: error sending request for url (https://api.openai.com/v1/responses)

  1. I also tried:
  • launching codex from the exact same shell as curl
  • explicitly passing proxy-related env vars when starting codex
  • upgrading Codex CLI to the latest version

The failure still happens.

  1. After logging out, I tried ChatGPT device-code login on this headless Linux server:

codex login --device-auth

That also fails, with:
error sending request for url (https://auth.openai.com/api/accounts/deviceauth/usercode)

So in this environment:

  • direct curl to https://api.openai.com/v1/responses works
  • Codex CLI request path to https://api.openai.com/v1/responses fails
  • Codex CLI device-auth request path to https://auth.openai.com/api/accounts/deviceauth/usercode also fails

This makes it look like the CLI’s HTTP/proxy/TLS handling is behaving differently from curl in the same environment.

What steps can reproduce the bug?

  1. Prepare a Linux server that accesses the internet through an HTTP proxy.
  1. Export the proxy environment variables in the shell where Codex CLI will be launched, for example:

export https_proxy=http://<proxy-host>:<proxy-port>
export http_proxy=http://<proxy-host>:<proxy-port>

  1. Verify that direct OpenAI API access works with curl from the same shell:

curl -N -v https://api.openai.com/v1/responses -H "Content-Type: application/json" -H "Authorization: Bearer $OPENAI_API_KEY" -d '{"model":"gpt-5.2","input":"say hello","stream":true}'

  1. Launch Codex CLI from that same shell:

codex

  1. Send any prompt in Codex CLI.
  1. Observe that the request fails with:

Stream disconnected before completion: error sending request for url (https://api.openai.com/v1/responses)

  1. Log out and try device-code authentication:

codex logout
codex login --device-auth

  1. Observe that device auth also fails with:

error sending request for url (https://auth.openai.com/api/accounts/deviceauth/usercode)

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

9 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #14583
  • #15447
  • #16052

Powered by Codex Action

etraut-openai contributor · 3 months ago

This sounds specific to your proxy configuration. You'll need to investigate further and diagnose the problem.

github-yxb · 3 months ago
This sounds specific to your proxy configuration. You'll need to investigate further and diagnose the problem.

Thanks. I agree the proxy is part of the environment, but I don't think this has been narrowed down to "just a proxy misconfiguration" yet.

Here is why I opened the issue:

  • curl to https://api.openai.com/v1/responses works from the same Linux server
  • the request is streamed successfully through the same proxy
  • codex fails from the same shell session, with the same proxy env vars
  • I also tried explicitly passing the proxy env vars and upgrading to the latest Codex version
  • after codex logout, codex login --device-auth also fails on https://auth.openai.com/api/accounts/deviceauth/usercode
github-yxb · 3 months ago

I have a useful update.

As a workaround, I asked another AI tool to generate a small local proxy service. It runs as an HTTP server on 127.0.0.1:9999, accepts Codex requests locally, and then forwards them to OpenAI through my existing proxy setup.

After that, I updated ~/.codex/config.toml to use the local service:

[model_providers.OpenAI]
name = "OpenAI"
base_url = "http://127.0.0.1:9999/v1"
wire_api = "responses"
requires_openai_auth = true

With this configuration, Codex works.

To me, this strongly suggests the issue is not simply “my proxy is broken”. The same environment fails when Codex talks to OpenAI directly, but succeeds when Codex talks to a local HTTP service that forwards the request through the proxy.

That points to some difference in how Codex handles direct outbound proxy/TLS/networking compared with other clients.

This workaround took hours to figure out, so I do think this issue deserves investigation, even if the root cause is an interaction with certain proxy environments.

928234269 · 3 months ago
This sounds specific to your proxy configuration. You'll need to investigate further and diagnose the problem.这听起来像是你的代理配置问题。你需要进一步调查并诊断问题所在。

I also encountered the same problem. I looked into many issues, but it seems that the developers never regarded this as a problem. It's quite strange. Have they ever used Codex in the proxy scenario themselves?

iamryanchia · 3 months ago

Encounter the same problem

MichaelErmer · 2 months ago

PSA: The issue is with TLS, you need to have your proxy/gateway support TLS1.2 until codex (Mac ARM) is fixed to support TLS1.3

Haxel0rd · 5 days ago

There is clearly some issue with codex app about this,- in my case update to latest codex caused the same error, while minutes before everything was fine. I was not running traffic through any proxy and the issue also persists with reboot, while everything else works fine and as usual.

Haxel0rd · 4 days ago

Was able to get codex working again for me, in my case the DNS resolution in WSL instance was broken, you can confirm it with running this in your WSL machine:

curl -v https://auth.openai.com

If this says name or service not known and the following ping returns normal answer:

ping 8.8.4.4

Then your issue is most likely in

/etc/resolv.conf

Quickfix: set google DNS as nameserver. This should make codex work again and from that moment on you can tell him to find out why it happened in the first place. resolv.conf should look something like this then:

user@wsl:\~$ cat /etc/resolv.conf nameserver 8.8.8.8 nameserver 8.8.4.4 options timeout:2 attempts:2 user@wsl:\~$

and curl to auth.openai.com should now work again.

== UPDATE ==

found the source of the problem, it seems to be an issue with stale HSN Firewall rules. I used the following commands, found under https://learn.microsoft.com/en-us/windows/wsl/troubleshooting under "Troubleshooting DNS in WSL" under point 4.:

PS C:\Windows\system32> wsl --shutdown PS C:\Windows\system32> Get-NetFirewallRule -Name "HNS*" | Get-NetFirewallPortFilter | where Protocol -eq UDP | where LocalPort -eq 53 | Remove-NetFirewallRule PS C:\Windows\system32> hnsdiag.exe delete all PS C:\Windows\system32> Restart-Service hns

(note this will remove firewall rules for port 53/udp, usually not a problem unless you have explicit custom setup there).

Then set DNS to local resolver and it my old setup before the quickfix (setting google dns), was working again as usual.