Desktop app hangs on Thinking indefinitely on macOS; forcing external codex fixes it

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

• #13682
• #12196
• #13666

Powered by Codex Action

Thanks a lot — this worked for me too.

I had the same macOS issue where Codex App / VSCode would hang on prompts. After applying your workaround and restarting, both came back to normal.

Really appreciate you posting this.

Works for me as well! thanks.

Same symptom on macOS 26.5 with Codex Desktop 26.602.30954 — and importantly, the CODEX_CLI_PATH workaround does not fix it here.

Root cause from the app-server log DB: every thread/start emits WARN unknown feature key in config: thread_tools, after which the turn never starts (UI: "Unable to send message / Loading…").

I string-checked three app-server builds for thread_tools:

• stable 0.137.0 → not present
• bundled 0.137.0-alpha.4 → not present
• npm alpha 0.138.0-alpha.4 → not present

So pointing CODEX_CLI_PATH at any currently-published CLI still stalls, because none implement thread_tools. The CLI itself is fully healthy (codex exec completes a turn; codex doctor = 0 fail). Looks like the 26.602 desktop client injects a feature flag that no released app-server understands — a client↔app-server version skew.

Repro: thread/start request_id e05ef332-8989-4da5-b102-3e4bf5314b3b; installation_id c6b6c580-d1d3-4314-a172-63965b51e0eb. Related: #13869.

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

I got a question before applying the changes:
Will it affect Codex Mobile? I think Codex Mobile (on ChatGPT iOS) is using two different protocols. The default account based is purely on ChatGPT account/Codex Desktop sync. The ssh-based is purely on Codex terminal. The ssh-based Codex Mobile can conflict with Codex Desktop when new messages are sent in different ways.

Adding a current macOS data point because this is still happening on a much newer Codex Desktop build, and the impact is severe for heavy daily use.

I am a very heavy Codex Desktop user. The failure mode is not just "the model is slow": after I send a prompt, the UI can remain at Thinking for a long time with no visible tool/action progress and no useful indication of what Codex is waiting on. In practice it looks idle from the user's point of view. Interrupting/resuming often makes the session responsive again, which makes this feel like a stalled turn/state-machine/streaming problem rather than legitimate long-running reasoning.

Current environment

• Codex Desktop: 26.623.81905
• Bundle build: 4598
• Bundle id: com.openai.codex
• Bundled CLI: codex-cli 0.142.5
• Platform: Darwin 24.6.0 arm64 arm
• macOS: 15.6.1 (24G90)
• Machine: Apple M4
• Codex Framework / Chromium version shown by running processes: 149.0.7827.197
• App server process: ~/Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled
• launchctl proxy / override env at time of collection: no HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, or CODEX_CLI_PATH set

Observed behavior

1. Use the macOS Codex Desktop app normally across coding tasks and threads.
2. Send a prompt.
3. Codex enters Thinking.
4. Sometimes it remains there for a long time with no visible tool call, terminal activity, progress heartbeat, retry message, or clear waiting reason.
5. Manual interruption/resume can make the task proceed again.

This is especially damaging because the user cannot distinguish:

• model is legitimately still reasoning,
• the Responses stream disconnected and is retrying,
• app-server is stuck,
• renderer/UI state is stale,
• Codex is waiting for a hidden/failed tool state,
• or no useful work is happening at all.

Local diagnostic signals

I queried the local Codex log DB in read-only mode and did not upload raw session JSONL because it contains private prompts and workspace data.

Local DB summary:

• Log DB: ~/.codex/logs_2.sqlite
• Covered interval: 2026-06-23 10:16:42 to 2026-07-03 09:53:17 local time
• Total rows: 103476
• Last 7 days:
• WARN: 929
• ERROR: 26
• codex_core::responses_retry warnings: 9 across 7 distinct threads
• codex_protocol::openai_models warnings: 31 across 31 distinct threads

Representative warning pattern, redacted to avoid private prompt/workspace disclosure:

codex_core::responses_retry:
stream disconnected - retrying sampling request (.../5 in ~200ms)

I specifically checked the thread_tools hypothesis mentioned above. On this machine I did not find WARN/ERROR rows containing thread_tools; matches were only query echo / TRACE or DEBUG rows from this investigation. So this may share the same user-visible symptom as earlier version-skew reports but not the exact same local signature.

There were also repeated codex_models_manager::manager 401 token_invalidated errors on 2026-06-30 from an older client_version=0.142.2, but I do not want to over-attribute the current Thinking stalls to that older auth event because current Codex Desktop is 26.623.81905 / 0.142.5 and is generally able to process turns.

Expected behavior

Thinking should never be an unbounded opaque state.

If Codex is still doing useful work, the Desktop UI should expose a reliable progress reason, for example:

• waiting for model stream,
• retrying after stream disconnect,
• waiting on app-server,
• waiting for a tool,
• waiting for user approval,
• compacting context,
• reconnecting,
• or failed with an actionable error.

If no progress has occurred for a threshold, Codex should have a watchdog that surfaces a recoverable error and captures enough telemetry for the team to diagnose the stuck state.

Why I think this should be prioritized

This is a reliability issue, not a cosmetic UI issue. For a coding agent, an indefinitely opaque Thinking state breaks user trust: the user does not know whether to wait, interrupt, restart, or risk corrupting/losing the current turn state.

There are already multiple related reports across Desktop surfaces, including:

• #13709
• #29780
• #26235
• #24287
• #24850

Please treat this as a high-priority Desktop/app-server reliability bug. I am happy to provide redacted local log excerpts or private session/thread identifiers if there is a secure path to share them without exposing prompts or repository contents.