Codex is very slow to respond
What version of Codex CLI is running?
codex-cli 0.116.0
What subscription do you have?
chatgpt sign in
Which model were you using?
gpt-5.4
What platform is your computer?
_No response_
What terminal emulator and version are you using (if applicable)?
_No response_
What issue are you seeing?
Codex CLI responses are extremely slow, and this issue started recently after updating Codex.
Every time I open the Codex app and send a prompt, it takes around 10 minutes or more to get a response, even for very simple questions.
I have tried multiple methods to fix this issue, but nothing works.
I am using macOS, and I am confident that my network is not the problem, because ChatGPT web works very smoothly on the same machine and network.
My subscription is active and has not expired.
This issue seriously affects usability.
What steps can reproduce the bug?
- Open Codex CLI on macOS
- Start a new session
- Send a simple prompt (e.g., a basic question)
- Wait for the response
Result: The response takes around 10 minutes or longer.
Expected: Response should be returned within a few seconds.
Uploaded thread: 019d0c1e-6ea5-7630-85c2-49895cddd24c
What is the expected behavior?
_No response_
Additional information
_No response_
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
This issue started immediately after updating Codex CLI.
It happens every time, not occasionally.
I’m experiencing the same issue. Codex often takes several minutes to respond, even in a new project containing only a small Markdown file.
In one case, Codex took 14 minutes to handle an interactive SSH connection. During that delay, the SSH server timed out while waiting for the password. Codex then incorrectly reported the timeout as an SSH server or authentication problem.
This makes terminal-based work, especially interactive commands with timeouts, practically unusable.
Expected behavior: Codex should respond to terminal prompts promptly enough to complete interactive commands before they time out.
Changing VPN exit locations did not resolve the issue: Netherlands ~3 minutes, Toronto ~3 minutes, and New York ~2 minutes for a short response without tools. Other users in the US report normal latency. This suggests that the issue may be tied to account-level routing, service tier, or a backend assignment rather than the client’s geographic IP address.
The UI spends most of the delay at “Waiting for server.” Two consecutive responses without any tool calls took 138.5 and 136.6 seconds. Local skill/MCP/tool discovery previously took only 6–20 seconds, so it does not account for the majority of the latency.