You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
No I don't have a config.toml file, actually I was on 0.77.x, I thought it was an update issue, so I closed the chat, updated the npm package. But still the same issue.
It may be related: today (2026-01-08 14-50-00 UTC) I tried to use codex with the same configs (0.79.0, GPT-5.1-codex-max, GNU/Linux Ubuntu 24.04) and I get a different response: 401 Unauthorized. I checked my API KEY is still valid.
API KEY was refreshed yesterday to prevent API KEY related problems.
Uploaded a new feedback with thread ID 019b9e17-df3f-7ca0-bfd7-976ec216ef1e.
Tested codex with same environment (same project, folder, OS, codex 0.79.0, model GPT-5.1-codex-max medium), it's back to disconnected stream error. Traceback thread ID is 019ba1df-38ad-7be1-a0ee-7f341cee443b.
Tested the api key with a simple curl query to check working:
$ curl https://api.openai.com/v1/responses \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-d '{ "model": "gpt-4.1", "input": "Tell me a three sentence bedtime story about a unicorn." }'
{
"id": "resp_0315251588f5d51c006960bdd0df18819782a2fa615de1b712",
... # omissis #
}
Based on the logs, this looks like a basic network connectivity issue. Do you have any network proxy, VPN, or firewall configured on your machine or network? I think you'll need to do some diagnosis of your system to fix this.
I double-checked and the latest issue (updated to 0.80.0) was again 401 Unauthorized.
I found that Codex stores the last working API_KEY in ~/.codex/auth.json. After renaming that file and running Codex again, it prompted me to confirm the current environment API_KEY and then saved it to the same location.
So rotating OPENAI_API_KEY isn’t straightforward if the cached key is still present.
I also haven’t encountered the stream disconnect bug again.
Everything is working now. Thanks for the support.
Activity
etraut-openai commentedon Jan 7, 2026
Do you have a
config.tomlfile? If so, what options do you have configured in it?Do you suspect that this was a regression with 0.79? Was this working previously?
aris997 commentedon Jan 7, 2026
No I don't have a
config.tomlfile, actually I was on 0.77.x, I thought it was an update issue, so I closed the chat, updated the npm package. But still the same issue.aris997 commentedon Jan 8, 2026
It may be related: today (2026-01-08 14-50-00 UTC) I tried to use codex with the same configs (0.79.0, GPT-5.1-codex-max, GNU/Linux Ubuntu 24.04) and I get a different response:
401 Unauthorized. I checked my API KEY is still valid.Uploaded a new feedback with thread ID
019b9e17-df3f-7ca0-bfd7-976ec216ef1e.etraut-openai commentedon Jan 9, 2026
That seems to indicate that the API key you're using is not valid (e.g. the key is corrupt/incorrect or has been revoked).
Here's what I recommend:
aris997 commentedon Jan 9, 2026
Okay, just allocated a new api key.
Tested codex with same environment (same project, folder, OS, codex 0.79.0, model GPT-5.1-codex-max medium), it's back to
disconnected streamerror. Traceback thread ID is019ba1df-38ad-7be1-a0ee-7f341cee443b.Tested the api key with a simple curl query to check working:
etraut-openai commentedon Jan 9, 2026
Based on the logs, this looks like a basic network connectivity issue. Do you have any network proxy, VPN, or firewall configured on your machine or network? I think you'll need to do some diagnosis of your system to fix this.
aris997 commentedon Jan 12, 2026
I double-checked and the latest issue (updated to 0.80.0) was again 401 Unauthorized.
I found that Codex stores the last working
API_KEYin~/.codex/auth.json. After renaming that file and running Codex again, it prompted me to confirm the current environment API_KEY and then saved it to the same location.So rotating OPENAI_API_KEY isn’t straightforward if the cached key is still present.
I also haven’t encountered the stream disconnect bug again.
Everything is working now. Thanks for the support.
aris997 commentedon Jan 12, 2026
Indeed just found that connecting via a specific connection (Company intranet via eth) the stream gets disconnected.
Also connecting via VPN, company connection blocks it.
019bb273-5bb9-7fb1-aebc-4dff19ce1b2f.