macOS local Codex clients hang after sending prompts

Open 💬 11 comments Opened Mar 6, 2026 by EriiiirE

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

v0.111.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.4, gpt-5.3-codex high

What platform is your computer?

Darwin 25.3.0 arm64 arm-macos

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

Terminal.app and VS Code integrated terminal

What issue are you seeing?

Local Codex clients on my macOS machine hang after I send even the simplest prompt, while Codex Web works normally.

Affected local clients:

Codex CLI
Codex VS Code extension
Codex macOS app

Symptoms:

In interactive CLI mode, simple prompts like "who are you" keep working / hang and do not return a response.
In non-interactive mode, commands like:

codex exec --skip-git-repo-check -m gpt-5.4 "Print exactly ok"
hang after printing:

user
Print exactly ok
mcp startup: no servers

Sometimes I also see:

failed to refresh available models: timeout waiting for child process to exit

Additional observation:

Codex Web works normally with the same account.
The issue affects local clients only.

What steps can reproduce the bug?

On macOS, install and launch Codex CLI v0.111.0.
Log in successfully with ChatGPT.
Run either:

codex --model gpt-5.4
and send a simple prompt like:
who are you
OR run:
codex exec --skip-git-repo-check -m gpt-5.4 "Print exactly ok"

Observe that the local client hangs and does not return a response.

I reproduced this in:

Terminal.app
VS Code integrated terminal
Codex macOS app
VS Code Codex extension

Codex Web does not reproduce the issue and works normally.

What is the expected behavior?

The local Codex client should return a response quickly for simple prompts.

For example:

codex exec --skip-git-repo-check -m gpt-5.4 "Print exactly ok" should print ok
interactive prompts like who are you should return a normal response instead of hanging

Additional information

What I already tried:

cleared ~/.codex
logged out and logged back in
reinstalled Codex via npm
reinstalled Codex via Homebrew
tested both Terminal.app and VS Code integrated terminal
killed all codex processes with pkill -9 -f codex

Network / proxy notes:

env | grep -i proxy is empty
scutil --proxy showed a system proxy via Verge on 127.0.0.1:7897
disabling the system proxy changed the symptoms slightly, but the local clients still remained broken
OpenClaw gateway port 18789 was not listening, so OpenClaw itself does not seem to be the direct cause

This started on Mar 6. The same machine worked previously.

View original on GitHub ↗

11 Comments

github-actions[bot] contributor · 4 months ago

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

#13710
#13666
#13406
#13682
#13709

Powered by Codex Action

aslaii · 4 months ago

Having the same issue here.

suosui · 4 months ago

same

CodesbyRobot · 4 months ago

Latest update codex macos app 26.305.950 hangs the models without doing anything (5.3 codex high). Model is just not reponsive. My guess is they slowed the models to make us try the '2x' fast mode :|

Tswatery · 4 months ago

same issue i can't use TUI or extensions.

EriiiirE · 4 months ago

Update: this is fixed for me by the workaround described in #13709.

What worked in my case:

force Codex Desktop / app-side worker to use the external CLI binary
make sure the proxy env vars are visible to GUI apps via launchctl setenv

Commands I used:

launchctl setenv CODEX_CLI_PATH /opt/homebrew/bin/codex
launchctl setenv HTTP_PROXY http://127.0.0.1:7897
launchctl setenv HTTPS_PROXY http://127.0.0.1:7897
launchctl setenv ALL_PROXY http://127.0.0.1:7897

After restarting Codex App / VSCode, both started working again.

So for anyone hitting the same “stuck on Thinking / no response” issue on macOS, #13709 is worth trying.

EriiiirE · 4 months ago

Having the same issue here.

Update: this is fixed for me by the workaround described in #13709.

What worked in my case:

force Codex Desktop / app-side worker to use the external CLI binary
make sure the proxy env vars are visible to GUI apps via launchctl setenv

Commands I used:

After restarting Codex App / VSCode, both started working again.

So for anyone hitting the same “stuck on Thinking / no response” issue on macOS, #13709 is worth trying.

EriiiirE · 4 months ago

same

Update: this is fixed for me by the workaround described in #13709.

What worked in my case:

force Codex Desktop / app-side worker to use the external CLI binary
make sure the proxy env vars are visible to GUI apps via launchctl setenv

Commands I used:

After restarting Codex App / VSCode, both started working again.

So for anyone hitting the same “stuck on Thinking / no response” issue on macOS, #13709 is worth trying.

EriiiirE · 4 months ago

Latest update codex macos app 26.305.950 hangs the models without doing anything (5.3 codex high). Model is just not reponsive. My guess is they slowed the models to make us try the '2x' fast mode :|

Update: this is fixed for me by the workaround described in #13709.

What worked in my case:

force Codex Desktop / app-side worker to use the external CLI binary
make sure the proxy env vars are visible to GUI apps via launchctl setenv

Commands I used:

After restarting Codex App / VSCode, both started working again.

So for anyone hitting the same “stuck on Thinking / no response” issue on macOS, #13709 is worth trying.

EriiiirE · 4 months ago

same issue i can't you TUI or extensions.

Update: this is fixed for me by the workaround described in #13709.

What worked in my case:

force Codex Desktop / app-side worker to use the external CLI binary
make sure the proxy env vars are visible to GUI apps via launchctl setenv

Commands I used:

After restarting Codex App / VSCode, both started working again.

So for anyone hitting the same “stuck on Thinking / no response” issue on macOS, #13709 is worth trying.

steipete · 2 months ago

Additional evidence from OpenClaw automation on Apr 30, 2026:

We reproduced the same failure mode through Codex app-server, not only the interactive CLI/App UI.

Observed run:

Provider/model: openai-codex/gpt-5.5
Codex process: codex app-server --listen stdio://
OpenClaw submitted the prompt and recorded only:
session.started
context.compiled
prompt.submitted
The per-run trajectory never received a model chunk / completion / terminal event for ~25-30 minutes.
The codex app-server parent + native vendor child stayed alive the whole time.
OpenClaw's queue had no pending backlog (queueDepth=0); diagnostics reported an active embedded run, so this was not an OpenClaw queue lock.

A previous run showed the same shape: it sat silent until the 30 minute outer cron timeout, then produced only a late one-line acknowledgement (Runbook loaded...) rather than useful task output.

OpenClaw-side workaround we added:

Our LLM idle watchdog previously only started once the provider had resolved a stream object.
For Codex app-server, this hang appears to happen before the promised stream resolves, so our 120s idle watchdog was not active yet.
We patched OpenClaw to also race the Promise<stream> resolution and fail fast with LLM idle timeout (...) if Codex never returns the stream.
Tracking/workaround issue: https://github.com/openclaw/openclaw/issues/75205

This does not fix the Codex-side issue: Codex app-server can still accept a prompt, keep the process alive, and never resolve/deliver the response stream. The OpenClaw change just prevents our automation from waiting the full outer cron timeout and spamming stuck-session diagnostics.