All models — Codex CLI hangs indefinitely on all prompts, no response generated

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

• #13726
• #13774
• #13715

Powered by Codex Action

It sounds like you suspect this is a regression? Let's see if we can confirm that because it will inform prioritization. If you downgrade to 0.111.0, does the problem go away?

No, it doesn't go away after updating. And I also noticed it happens on 5.3 as well.

OK, then this isn't a regression. I don't think we've received other reports of this, so it's possible that this is specific to your system. Perhaps you changed something recently in your shell configuration or Codex configuration? Or maybe there's something corrupt within your .codex directory.

I have the same problem.

OK, then this isn't a regression. I don't think we've received other reports of this, so it's possible that this is specific to your system. Perhaps you changed something recently in your shell configuration or Codex configuration? Or maybe there's something corrupt within your .codex directory.

Nothing has changed. It stopped working after the release of gpt 5.4 :(.

Same problem (gpt-5.4 and gpt-5.3-codex), happens predominantly right around forced compaction time (10-20%). I have to remind myself to /compact or risk being stuck for 30+ minutes.

'Remote compaction task' also fails more often. Problem seems serverside (session cache invalidation?). I'm able to get a quick response in a new chat, but even codex fork on the old (long) chat leads to a long (and quiet) stall.

codex-cli 0.113.0-alpha.1 and macOS app Version 26.305.950 (863) (codex-cli 0.108.0-alpha.12)

EDIT: still happens after rotating VPN IP and cp auth.json dance to switch ChatGPT accounts. After around 15 minutes it timed out with Error running remote compact task: stream disconnected before completion: error sending request for url
(https://chatgpt.com/backend-api/codex/responses/compact), seems unrelated to server caches. Quiet compaction overrun, buffer too small?

Yes I am having the same issue. Started right after I updated to the newest version 10 minutes ago. Was working before the update. After I send a message I dont get any response, and the cli just hangs.

Having the same issue. 10 minutes ago.

v0.112.0. It worked fine ten minutes ago in the same version, but suddenly it just hangs on every message.

I have the same issue which started to happen today after I've updated to v0.112.0.
Box: Arch Linux
Behavior: Worked well after update for a hour or two, right now all prompts do not have any responses.
Even the command /exit does not work so I have to kill codex from the process list.

RUST_LOG='codex_api::sse::responses=trace' codex exec --sandbox read-only --model gpt-5.3-codex 'ping'
OpenAI Codex v0.112.0 (research preview)
--------
workdir: ...
model: gpt-5.3-codex
provider: openai
approval: never
sandbox: read-only
reasoning effort: xhigh
reasoning summaries: none
session id: 019cd167-d5c3-7691-a3af-ce39bd4ca827
--------
user
ping
2026-03-09T07:02:56.577787Z TRACE codex_api::sse::responses: unhandled responses event: response.in_progress
2026-03-09T07:02:58.437882Z TRACE codex_api::sse::responses: unhandled responses event: response.in_progress
2026-03-09T07:03:02.608218Z TRACE codex_api::sse::responses: unhandled responses event: response.content_part.added
2026-03-09T07:03:02.708617Z TRACE codex_api::sse::responses: unhandled responses event: response.output_text.done
2026-03-09T07:03:02.708654Z TRACE codex_api::sse::responses: unhandled responses event: response.content_part.done
codex
pong
tokens used
17,582

I think I just found the issue. It looks like the response is not handled at all; only the result is printed.

`` RUST_LOG='codex_api::sse::responses=trace' codex exec --sandbox read-only --model gpt-5.3-codex 'ping' OpenAI Codex v0.112.0 (research preview) -------- workdir: ... model: gpt-5.3-codex provider: openai approval: never sandbox: read-only reasoning effort: xhigh reasoning summaries: none session id: 019cd167-d5c3-7691-a3af-ce39bd4ca827 -------- user ping 2026-03-09T07:02:56.577787Z TRACE codex_api::sse::responses: unhandled responses event: response.in_progress 2026-03-09T07:02:58.437882Z TRACE codex_api::sse::responses: unhandled responses event: response.in_progress 2026-03-09T07:03:02.608218Z TRACE codex_api::sse::responses: unhandled responses event: response.content_part.added 2026-03-09T07:03:02.708617Z TRACE codex_api::sse::responses: unhandled responses event: response.output_text.done 2026-03-09T07:03:02.708654Z TRACE codex_api::sse::responses: unhandled responses event: response.content_part.done codex pong tokens used 17,582 `` I think I just found the issue. It looks like the response is not handled at all; only the result is printed.

Interesting. From my side it just hangs and no response are coming

RUST_LOG='codex_api::sse::responses=trace' codex exec --sandbox read-only --model gpt-5.3-codex 'ping'
OpenAI Codex v0.112.0 (research preview)
--------
workdir: /home/checker
model: gpt-5.3-codex
provider: openai
approval: never
sandbox: read-only
reasoning effort: xhigh
reasoning summaries: none
session id: 019cd16c-08a0-7752-83ba-eaa296f4dde2
--------
user
ping
mcp startup: no servers

My hunch is (oversized) remote compaction tasks. Wish we had #13087 and #14024 already, to fork thread right before the problematic message that pushes it over the compaction buffer limit. Now I'm cucked. 🐀

#14054 reports another recent compaction issue, but that's even without a lengthy session. This is affecting multiple users right now across multiple apps (even stable desktop app, a few CLI versions behind), suggesting a serverside problem (not CLI regression), @etraut-openai.

Possibly related (Reddit): chatgpt_54_1m_context_is_actually_900k_context

using gpt-5.4 via /v1/messages. Results: Success at ~540,007 input tokens Success at ~630,007 input tokens Success at ~720,007 input tokens Success at ~750,007 input tokens Success at ~800,017 input tokens Success at ~840,007 input tokens Success at ~900,007 input tokens Failure around ~950,010 and 1,000,020 input tokens with: 408 stream disconnected before response.completed then temporary 500 auth_unavailable until the account recovered Conclusion: Your current setup is stable up to ~900k input tokens. Around 950k–1.0M becomes unstable on this account/path.

'Compaction death spiral' (#13279) could also eat a lot of tokens.

I'm getting the same on MacOS. I thought it was related to 0.112.0, but when I downgraded to the previous version I was using (0.110.0) I ran into the same issue. It's happening on startup, so the issue I'm encountering is not related to compaction.

> `` > RUST_LOG='codex_api::sse::responses=trace' codex exec --sandbox read-only --model gpt-5.3-codex 'ping' > OpenAI Codex v0.112.0 (research preview) > -------- > workdir: ... > model: gpt-5.3-codex > provider: openai > approval: never > sandbox: read-only > reasoning effort: xhigh > reasoning summaries: none > session id: 019cd167-d5c3-7691-a3af-ce39bd4ca827 > -------- > user > ping > 2026-03-09T07:02:56.577787Z TRACE codex_api::sse::responses: unhandled responses event: response.in_progress > 2026-03-09T07:02:58.437882Z TRACE codex_api::sse::responses: unhandled responses event: response.in_progress > 2026-03-09T07:03:02.608218Z TRACE codex_api::sse::responses: unhandled responses event: response.content_part.added > 2026-03-09T07:03:02.708617Z TRACE codex_api::sse::responses: unhandled responses event: response.output_text.done > 2026-03-09T07:03:02.708654Z TRACE codex_api::sse::responses: unhandled responses event: response.content_part.done > codex > pong > tokens used > 17,582 > ` > > > > > > > > > > > > I think I just found the issue. It looks like the response is not handled at all; only the result is printed. Interesting. From my side it just hangs and no response are coming ` RUST_LOG='codex_api::sse::responses=trace' codex exec --sandbox read-only --model gpt-5.3-codex 'ping' OpenAI Codex v0.112.0 (research preview) -------- workdir: /home/checker model: gpt-5.3-codex provider: openai approval: never sandbox: read-only reasoning effort: xhigh reasoning summaries: none session id: 019cd16c-08a0-7752-83ba-eaa296f4dde2 -------- user ping mcp startup: no servers ``

okay it hangs indefinitely for me now as well.....

---

edit: after waiting for ~5 mins, it outputs "pong"

My hunch is (oversized) remote compaction tasks. Wish we had #13087 and #14024 already, to fork thread right before the problematic message that pushes it over the compaction buffer limit. Now I'm cucked. 🐀 #14054 reports another recent compaction issue, but that's even without a lengthy session. This is affecting multiple users right now across multiple apps (even stable desktop app, a few CLI versions behind), suggesting a serverside problem (not CLI regression), @etraut-openai. Possibly related (Reddit): chatgpt_54_1m_context_is_actually_900k_context > using gpt-5.4 via /v1/messages. > Results: > Success at ~540,007 input tokens > Success at ~630,007 input tokens > Success at ~720,007 input tokens > Success at ~750,007 input tokens > Success at ~800,017 input tokens > Success at ~840,007 input tokens > Success at ~900,007 input tokens > Failure around ~950,010 and 1,000,020 input tokens with: > 408 stream disconnected before response.completed > then temporary 500 auth_unavailable until the account recovered > Conclusion: > Your current setup is stable up to ~900k input tokens. > Around 950k–1.0M becomes unstable on this account/path. 'Compaction death spiral' (#13279) could also eat a lot of tokens.

Don't think it is related to compaction. It happens on startup for me.

Has anyone solved it?

tokens used 17,582

@songkeys: well shit, only 17,582 tokens? No compaction needed. There goes my theory, @galcianuk.

• Model changed to gpt-5.1-codex-mini medium › house every weekend <silence>

New chat now also fails, but at least it doesn't hang. Few seconds of 'Thinking', then no response.

But now CTRL-C doesn't even work (CLI). Let's see if OpenCode works with ChatGPT plans.

EDIT: after 5 minutes (5m 2s), CTRL-C finally exited the CLI.

You can try to call RUST_LOG=trace codex exec --sandbox read-only --model gpt-5.4 'ping' and watch the noisy output. Seems that something is related to remote use case.

Same issue here, switching model or downgrade codex version doesn't help, it's just hang up without any output.

I completely removed the .codex directory, and that solved the issue. Honestly, the previous .codex directory was easy to understand, but now it's extremely hard to understand.

You can try to call RUST_LOG=trace codex exec --sandbox read-only --model gpt-5.4 'ping' and watch the noisy output. Seems that something is related to remote use case.

You can see that codex is doing a lot of calls with ping and pong responses. Probably the new version has been created more calls on their websocket servers. I see that some pings now works fast, some still hands.

Just tried OpenCode with the same ChatGPT account to rule out a ~/.codex issue. It took 1m 6s to respond.

<img width="749" height="420" alt="Image" src="https://github.com/user-attachments/assets/fb73c999-b0c9-4682-ba84-61b6d454323e" />

Does your account still work, @iwangjie? I tried two accounts and different VPN IPs.

@nilswx Try deleting the .codex directory and downgrading to 0.111.0, it should work then.

Not resolved, @iwangjie. Both accounts still frozen/throttled, even in OpenCode. Silent rate limiter flag on the account?

Error running remote compact task: stream disconnected before completion: error sending reque
st for url (https://chatgpt.com/backend-api/codex/responses/compact) after exactly 5 minutes.

I'm backing off until we learn more. Best not risk more usage (#14059).

I deleted the sandbox-related content in config.toml,and downgade to 0.111.0,then it works.

My issue is not limited to GPT-5.4. It happens with all models.
My platform is a Macbook with an M1 chip. I have tried uninstalling and reinstalling codex-cli, the VS Code extension, and the Codex app, but the problem still persists.

I have the same problem

I had encountered same issue, after update to 0.112.0
but then I realized .codex/version.json latest_version still using 0.111.0
changing latest_version to 0.112.0 solved mine

I had encountered same issue, after update to 0.112.0 but then I realized .codex/version.json latest_version still using 0.111.0 changing latest_version to 0.112.0 solved mine

Mine is already 0.112.0. Not working.

{"latest_version":"0.112.0","last_checked_at":"2026-03-09T03:02:41.442470Z","dismissed_version":null}

Same here.

Same, with opencode and codex too, wait too long to receive the response

Codex TUI has stopped responding completely. Codex app goes into long Thinking mode.

<img width="824" height="727" alt="Image" src="https://github.com/user-attachments/assets/f0e6e462-dbc4-4140-b41a-85faada1d8a6" />

same on opencode and getting Bad Request: {"detail":"Bad Request"} a lot lately
GPT 5.4 seems to be working fine via github copilot though

<img width="2191" height="271" alt="Image" src="https://github.com/user-attachments/assets/82af3869-4783-413f-ae04-727040fe9bb7" />

Example of delayed responses when giving new prompt.

Same with on both opencode and codex. Web and API(through OpenRouter) work fine.

It happened on MacOS too

same i have this problem.

i was on the v0.111.0 version at first, it still occurs

i then updated to v0.112.0 and it still persists

Same here. MacOS 0.112.0.

i have the same problem after just updating the version of my codex cli

https://github.com/openai/codex/issues/13868

Please check https://chatgpt.com/cyber and see your cyber verification status.

In my case, the verification was not enabled at first, then it became verified earlier this morning. However, about 4 hours ago it was removed again.

Since then, all responses have become slow and many requests are not being processed properly.

I would appreciate it if you could check your cyber verification page and share your status as well.

---
Is this unrelated to the cyber verification issue?

My account shows that cyber verification has been removed. Could you please check why my account is showing as unverified?

its the sandbox_mode = "danger-full-access" in the config.toml. i deleted it and codex works as per normal

for some odd reason you need to wait 10 mins for codex after deleting sandbox_mode = "danger-full-access" then it works.

Downgrading to 0.110.0 fixed it.

I'm experiencing the same issue on Arch Linux and now on macOS as well.

On Arch Linux, I tested with versions 111 and 112, and both show the same problem.
On macOS, I tested with version 110. It was working fine until about 20 minutes ago — no updates or configuration changes on my side — but it suddenly stopped working as well.

Quick question for others encountering this: are you using Codex via your ChatGPT account, or through the API?

Example minimal test:

codex exec --skip-git-repo-check --sandbox danger-full-access "dis juste ok"

Output:

OpenAI Codex v0.110.0 (research preview)

workdir: /home/jithurbide
model: gpt-5.3-codex
provider: openai
approval: never
sandbox: danger-full-access
reasoning effort: none
reasoning summaries: none
session id: 019xxxxxxxxxxxxxxx
user
dis juste ok
mcp startup: no servers

After that, nothing happens. The process just hangs.

It's also happening with the codex app and the chatgpt app has been very slow, so it seems to be an API issue. Strangely though, I can use GPT 5.4 in Cursor with no problem

I had this issue throughout several versions. I have the impression that it has something to do with the interaction with the repository one currently uses. I got this "no response" when I worked in different directories. When I just copy the content (without git) to a completely clean folder and start codex from that folder after a new git init, then it does respond to requests again. If I go back to the old folder and start codex, I still get no response

I've now suddenly got this problem after upgrading to 0.112.0. Downgrading to 0.111.0 or 0.110.0 doesn't fix it. It doesn't respond to "ctrl + c"; I have to press "ctrl + z" to suspend and then manually kill the process.

I'm using Ubuntu 24 and I installed codex via sudo npm install.

It's back working for me now. didn't do anything. Must have been fixed on OpenAI end. Please check whether it works for you.

same to me

I've now suddenly got this problem after upgrading to 0.112.0. Downgrading to 0.111.0 or 0.110.0 doesn't fix it. It doesn't respond to "ctrl + c"; I have to press "ctrl + z" to suspend and then manually kill the process. I'm using Ubuntu 24 and I installed codex via sudo npm install.

same here on almalinux-release-9.7-1.el9.aarch64

just hangs on first prompt, nothing happens, no ctrl+c, only ctrl+z + kill

im running on a vm

EDIT:

• downgrading to v0.110.0 did not fix it
• also hangs with sdk usage
• when reopening, and i press arrow up, it doesn't show me the last message sent, only much older, even those that did previously work
• running via ghosty

EDIT 2:

• actually it does work, it is just hangs for quite some time and then works?

FWIW it hangs for me on alacritty but not on gnome-terminal. I suspect some terminal interaction is going wrong. (Ubuntu 25.10)

Seems to be fixed now

Same to me after update to v0.112.0 (Mac)

great stuff
v112.0
Macos
<img width="620" height="726" alt="Image" src="https://github.com/user-attachments/assets/31343eb8-769f-4bd5-9888-6acae9e62531" />

Same issue, nothing is working

FWIW it hangs for me on alacritty but not on gnome-terminal. I suspect some terminal interaction is going wrong. (Ubuntu 25.10)

Same here. What’s strange is that it seems related to the terminal being used.

On my Mac:

• Using iTerm2 locally → works

On a remote host:

• Using iTerm2 → hangs
• Using WezTerm → works

So the behavior seems to depend on the terminal emulator and/or how the TTY is handled over SSH.

Same here, MacOS 26.3.1 (25D2128). I tried with Warp, Terminal, the terminal inside IntelliJ IDEs and I get the same result in all the tests (no response from Codex).

Edit: I was with version 0.111.0, upgrading to 0.112.0 did not fix it.

Same here, codex was extremely slow today and right now doesn't work at all

UPD: downgrading to 0.110.0 helped

UPD2: it helped only for a short time, broke again

i also ran into this issue. just waiting for a while works. only noticed this on new sessions in the CLI. here is MiniMax 2.5's analysis using claude code

macos 26.3.1
tried with v0.112, v0.111, and v0.110

Logs show:

  1. First session (08:34:44) - Initial session with full initialization:
    - Configuring session debug log appears
    - WebSocket connected successfully: successfully connected to websocket:
  wss://chatgpt.com/backend-api/codex/responses
    - User message "hello" submitted at 08:34:47
    - No response received - message submitted but no response logged
  2. Subsequent sessions (08:41, 08:56, 08:59) - Lighter weight sessions:
    - No Configuring session log - these are resumed/forked sessions
    - No WebSocket connection attempt at all
    - Sessions close quickly without trying to connect
  3. Previous warning (07:51) - Shows root cause:
  startup websocket prewarm setup failed: stream disconnected before completion: idle timeout waiting for websocket
    - This is a 5-minute timeout (DEFAULT_STREAM_IDLE_TIMEOUT_MS = 300_000)

OK, then this isn't a regression. I don't think we've received other reports of this, so it's possible that this is specific to your system. Perhaps you changed something recently in your shell configuration or Codex configuration? Or maybe there's something corrupt within your .codex directory.

I have the same problem after updating to codex latest version today on Mac. It does eventually accept the prompt after a while and afterwards it works just fine.
Problem is just the first prompt when we start/resume a session.
Was working just fine mins before I updated

consider updating the title of this issue since its not specific to 5.4 high

I don't know if this is relevant, but it happens on other harnesses too.

Uptime on OpenRouter seems good for now
Either it does not yet reflect the downtime or the issue only happens with chatgpt plus/pro etc subscription and not API keys

so, it's not terminal related - the problem is on their side? Do we just wait?

I had the same issue today on both the Mac CLI and the app. I’m on the Plus plan, and logging out and then back in fixed it for me.

same issue on VSCode with Codex plugin

I had the same issue today on both the Mac CLI and the app. I’m on the Plus plan, and logging out and then back in fixed it for me.

Can you try give us an update in 20 minutes whether this is still worked

@ClementV78

I had the same issue today on both the Mac CLI and the app. I’m on the Plus plan, and logging out and then back in fixed it for me.

not working for me

one data point i dont see mentioned in this thread: once you finally get the first response (if you do get it), at least for me, it works as usual.

old sessions that i had started before this issue are also still healthy.

It seems like starting new sessions and sending the first message is the blocker.

one data point i dont see mentioned in this thread: once you finally get the first response (if you do get it), at least for me, it works as usual. old sessions that i had started before this issue are also still healthy. It seems like starting new sessions and sending the first message is the blocker.

in my case old session gets stuck at "working" and i don't get actual answer back. Do you get answer back?

in my case old session gets stuck at "working" and i don't get actual answer back. Do you get answer back?

yes. im on a pro subscription, not sure if that matters but sharing for data.

I have the same issue which started to happen today after I've updated to v0.112.0. Box: Arch Linux Behavior: Worked well after update for a hour or two, right now all prompts do not have any responses. Even the command /exit does not work so I have to kill codex from the process list.

same for me, on aarch64 ubuntu. downgrade to 110, wiping codex dir and reinstalling did not help.

Same issue here

same

I had multiple Codex processes running simultaneously (same API key, Plus subscription). While
one session was actively making tool calls (running tests, applying patches), a second
session's submissions were completely silent — created but never processed. The second session
started working shortly after the first session's turn completed (codex_core::codex: close).

This suggests possible API-level queuing or rate limiting that Codex doesn't surface to the
user — no timeout, no error, no "waiting" indicator.

Environment:

• Codex v0.112.0
• macOS (Darwin 25.3.0, Apple Silicon)
• Models: gpt-5.4 medium, gpt-5.4 high
• Subscription: Pro
• Terminal: xterm.js via node-pty (also reproducible in native Terminal.app)

I've encountered a similar issue suddenly. The CLI starts quickly as usual, but then after any prompt it doesn't show the "working" status and just freezes. Even Ctrl+C doesn't stop it.

Some testing on my side has shown inconsistent results across attempts. Seems to be a backend issue.
<details>
<summary>Test results</summary>
<img width="1136" height="632" alt="Image" src="https://github.com/user-attachments/assets/3171978b-3428-40ca-a779-46a29b827ac9" />

<img width="806" height="642" alt="Image" src="https://github.com/user-attachments/assets/0ec6492a-b495-4082-a53b-afb597597520" />

<img width="1538" height="642" alt="Image" src="https://github.com/user-attachments/assets/2cdf3447-cdbe-408f-8c89-8ab1995f6dcd" />

<img width="802" height="624" alt="Image" src="https://github.com/user-attachments/assets/a7f51f8d-1f25-4fbd-b40f-d6d7ca0f6138" />
</details>

same here on MacOSX. I start codex in my workspace, enter the prompt, press ENTER and then .... nothing. /exit is ignored, CTRL+C is ignored. plain silence :-)

I had the same issue after updating to v0.112.0. It was just "hanging" on my Ubuntu machine (Chat-GPT Plus subscription). I tried different things, but in the end, I made it work. Here is what I did:

1. Upgrade to v0.112.0. The codex was hanging and not responding to the /exit or Ctrl+C command. So I just quit the terminal.
2. Downgrade to v0.111.0 and then to v0.110. This did not help.
3. Log out and log in again. Nothing.
4. Switched to the gpt-5.1-codex-mini model, wrote Hi, and waited for a response for about 10-15 minutes. After that, I was able to communicate and normally close the session using /exit.
5. However, other sessions were still hanging, so I manually killed all the codex-related processes:

<img width="1033" height="170" alt="Image" src="https://github.com/user-attachments/assets/753854b4-8eb9-400f-bfe0-76d55c59ca5d" />

1. Voilà, a new session worked!

So I do not know the exact solution, but it seems that waiting for the response and then killing other processes made it work.

I had the same issue after updating to v0.112.0. It was just "hanging" on my Ubuntu machine (Chat-GPT Plus subscription). I tried different things, but in the end, I made it work. Here is what I did: 0. Upgrade to v0.112.0. The codex was hanging and not responding to the /exit or Ctrl+C command. So I just quit the terminal. 1. Downgrade to v0.111.0 and then to v0.110. This did not help. 2. Log out and log in again. Nothing. 3. Switched to the gpt-5.1-codex-mini model, wrote Hi, and waited for a response for about 10-15 minutes. After that, I was able to communicate and normally close the session using /exit. 4. However, other sessions were still hanging, so I manually killed all the codex-related processes: <img alt="Image" width="1033" height="170" src="https://private-user-images.githubusercontent.com/34775595/560361286-753854b4-8eb9-400f-bfe0-76d55c59ca5d.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzMwNjgyMTQsIm5iZiI6MTc3MzA2NzkxNCwicGF0aCI6Ii8zNDc3NTU5NS81NjAzNjEyODYtNzUzODU0YjQtOGViOS00MDBmLWJmZTAtNzZkNTVjNTljYTVkLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjAzMDklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwMzA5VDE0NTE1NFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTc5ODgwY2YwYzgxNTY1NGFiYWNiNTcwNGEyZGE2ZmY1ZThhNjAxODg5M2M0OGQyYjcxNWQ3ZmQ5YzY0YjEzZDMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.b4L8qhpCMMhXuu8isXWZp4ypaGAZTxvwffVjhFyRWu8"> 6. Voilà, a new session worked! So I do not know the exact solution, but it seems that waiting for the response and then killing other processes made it work.

thanks, i just restarted my mac and i think it's working. i got replies from codex

Weird. It started working after about 5 minutes. Before that though, no output at all. /exit didn't work. ctrl-c didn't work. Nothing worked. No output at all, and no errors.

Status page has been updated: https://status.openai.com/incidents/01KK9JA8JKQKDW1W24T09NHBYH

it worked when I started codex without --yolo

I have the very same issue, no matter which model I choose, the response is never received, or with huge delays. I'm sure this is server-side, not client-side.

same issue
OS: Ubuntu 24.04
CodeX: 0.112.0
Model: gpt-5.4, gpt-5.3-codex

update:
so strange, it recovers as soon as I make this report

As someone who knows absolutely nothing about the infra and is just purely vibespeculating here as I wait for codex to start responding:

• waiting for a websocket connection to be routed to inference server but some subset fail to connect
• cli retries over and over but gets routed to same server until another is tried. By default, reqs go to the same server, as that is done for kv cache purposes
• this also explains why some people report it working on one account and not on another account
• once connection to a good server is established, everything works since the websocket stays open for entire thread

Thank you for listening to my totally ungrounded vibe analysis while I wait for stressed engineers at OpenAI HQ try to resolve this issue.

We're actively working on this issue. Thanks for all of the clues and analysis.

Something that might help us resolve this more quickly... Could several of you use /feedback to upload your logs and session details after this occurs? I realize that you may not be able to break in with a Ctrl+C immediately, but if it eventually responds, use /feedback and then post the thread ID here. Thanks!

The issue seems to have stopped for me

Something that might help us resolve this more quickly... Could several of you use /feedback to upload your logs and session details after this occurs? I realize that you may not be able to break in with a Ctrl+C immediately, but if it eventually responds, use /feedback and then post the thread ID here. Thanks!

019cd2fb-0949-7eb2-9dea-1c969693bfb1, 019cd2fe-deb0-7402-ae3a-73ae9431b400, and 019cd30d-2efa-7623-9dfe-44961260f6aa

It is improving, less blocks and delays at the moment also my side.

seems to have been fixed

I see improvements, I don't want to jinx it, but everything seems to be working stable now, at least for me

ID 019cd39c-1452-7522-bb36-df19eca1810d

Not fixed on my end.

same. also not fixed here: 019cd39f-0e08-7dd1-925f-832d0b5835bd

also here still having issues: 019cd434-724b-7131-88d3-d8c1696e19cb

We've taken steps to minimize the impact of this issue. There were a couple of unhealthy clusters, and we've rerouted traffic away from them. Most users who were previously affected should now be back up and running. Some may hit the problem until we have the root cause fully mitigated.

> I had the same issue today on both the Mac CLI and the app. I’m on the Plus plan, and logging out and then back in fixed it for me. Can you try give us an update in 20 minutes whether this is still worked @ClementV78

Yes it seems better for the moment but I had to start new context conversation. Thks

We think this is now fully mitigated. We'll continue to monitor closely.

Apologies for any inconvenience this caused.

I'm going to close the issue, but if you experience this symptom again within the next 24 hours, let us know.

thanks @etraut-openai

As a note, not resolved for me. Exactly the same issue.

As a note, not resolved for me. Exactly the same issue.

Me neither, same issue not resolved

Still facing same issue.

<img width="1111" height="522" alt="Image" src="https://github.com/user-attachments/assets/1896800d-77d1-4f97-97ad-3fbc7fc94ebf" />

It's not working in both Codex and OpenCode, very frustrated.

Seems to be fixed now

Was fixed yesturday at arround 17:00 PM GMT+9. Today it worked in the morning and at arround 12:00PM GMT+9 the problem has come back.

happening just now.

same for me

Same problem. I started having this since yesterday; before that, everything was fine.

@etraut-openai please re-open.

We think this is now fully mitigated. We'll continue to monitor closely. Apologies for any inconvenience this caused. I'm going to close the issue, but if you experience this symptom again within the next 24 hours, let us know.

@etraut-openai The same problem is happening again.

019cd6cb-54f6-7072-b8ef-a28edeb839c7

still happening my ubuntu and mac os

cli codex and ui both

yes still happening
reconnecting + slow + unresponsive

cli version v0.113.0 and app lastest version still happening

Is anybody updating homebrew cask for v0.113.0?

its back now. no need to do anything.
Go n try, everyone😜

<img width="633" height="359" alt="Image" src="https://github.com/user-attachments/assets/c7bd2253-c5e3-4b88-99fc-5efedb8720c4" />

its back now. no need to do anything. Go n try, everyone😜

Although the reconnect issue is no longer present, I still feel that the task execution time is abnormally long.

Oh... well, the problem hasn't been completely solved; it's just happening less frequently. Just now, at 6:00 PM (GMT+8), the same issue occurred again, that reconnecting five times problem.
019cd72f-97bc-7d13-a788-64c7d6ae163a

It's still dying on me

<img width="2447" height="72" alt="Image" src="https://github.com/user-attachments/assets/557ab700-67fa-424a-9863-8ab0ac96c72b" />

Working well for me now from several hours. Just signed out, signed in. Started new terminal session.

some people say its also not working in paid accounts too

Hitting this error in paid account.

This is fixed for me now. Thank you!

For me issue persists: 019cdc16-2f1f-7a73-a570-bd3ceec5a0c3

Still problems sometimes, it still gets stuck.

This time it was not for long, but I think it should say that it is waiting on something, if it does. Since now it just appears freezed without any feedback.

Uploaded thread: 019cdcdd-d0f5-79e3-9a5a-568adc7ce038

yep, still happening, in both cli and vscode extension, just freezing in thinking phase, no output, even can not quit in cli.

Agree problem is black. Thinking for ever.

Jup, also on my side

Still happening for me on a paid account, after logging out and logging back in again. Getting stuck on Thinking, disconnecting, then erroring out. Using the VSCode extension.

Same Issue here on linux as well, paid account.

Same issue for me. both in cli and vs extension.
cli version: 0.114.0
extension version: v26.311.21342
os: mac os 15.7.4 with M2 chip

Now, my solution is downgrade cli version to 0.100.0 and extennsion version to 0.4.76.

Please fix it ASAP

Same issue. Paid account, had to downgrade to 0.100.0

Same in MacOS. I downgraded to v0.100.0 to make it work. Other version after this one can't work too. This is a really breaking bug