Codex CLI and app both hang on macOS 26.4.1 (25E253). Process connects to API (ESTABLISHED TCP) but Tokio runtime parks indefinitely —
EricGT
May 19, 2026, 12:24pm
2
You are welcome to discuss Codex issues on the forum, however the official place to report and track them is the GitHub issue tracker for OpenAI Codex .
I did a quick search of __psynch_cvwait on the GitHub OpenAI Codex issues and this surfaced:
opened 02:47PM - 12 Mar 26 UTC
bug
exec
performance
### What version of Codex CLI is running?
`codex-cli 0.114.0`
### What subscri… ption do you have?
ChatGPT login via the local CLI. I did not verify the exact plan before filing this.
### Which model were you using?
`gpt-5.4`
### What platform is your computer?
`Darwin 24.6.0 arm64 arm`
### What terminal emulator and version are you using (if applicable)?
This repro comes from a non-interactive integration that spawns `codex exec --json ... resume ...` as a child process on macOS, not from an interactive terminal session.
### What issue are you seeing?
I am seeing a silent hang on `codex exec --json resume <session> <follow-up prompt>` on macOS.
What makes this one tricky is that the process does not fail fast and it does not look like a normal "tool call hung" case. The resumed `codex` process starts, launches MCP helper processes, and then just sits there for hours without emitting a new turn start, final answer, or completion event.
In my case:
- the resumed process stays alive until manually killed
- helper processes for `chrome-devtools-mcp`, `playwright-mcp`, and `mcp-server-fetch` are also still alive
- the rollout file never gets a new event for the resumed turn; the last persisted events are still from the previous completed turn
- sampling the stuck main process shows it mostly sleeping in `__psynch_cvwait`, `kevent`, and `read`, which looks more like an internal wait on IO/transport than active model work
This feels related to MCP startup / tool inventory, not to a specific tool call after the turn has already started.
It also seems close to #14115 and #6664, but not identical. In this case the hang appears earlier: during resumed-turn startup, before I see a new `TurnStarted`-style event or any MCP `tools/call`.
### What steps can reproduce the bug?
I have not reduced this to the smallest possible repro yet, but this is the pattern that reproduced reliably for me:
1. Use Codex CLI on macOS arm64 with several MCP servers configured. In my case those included:
- `chrome-devtools`
- `chrome_devtools`
- `fetch`
- `playwright`
- `stitch`
2. Start a normal session and let it complete at least one turn so the session has resumable history.
3. Run a follow-up through `resume`, for example:
```bash
codex exec --json \
--dangerously-bypass-approvals-and-sandbox \
--skip-git-repo-check \
--cd /redacted/worktree \
resume <session-id> 'follow-up prompt'
```
4. Observe that:
- the main `codex` process starts normally
- MCP helper processes start
- no new JSON events arrive for the resumed turn
- no final answer or completion event is produced
- the process remains stuck indefinitely
### What is the expected behavior?
One of these should happen:
- the resumed turn should start normally and emit its usual events, then finish
- or Codex should surface a real startup error
- or Codex should time out and fail explicitly instead of waiting forever
In other words, `resume` should not be able to wedge the whole process in a no-output state just because some internal startup path never resolves.
### Additional information
I dug through the current source before filing this, and the most suspicious path I found is:
- `built_tools(...)` calls `mcp_connection_manager.list_all_tools()`
- startup prewarm and normal turn setup both use `built_tools(...)`
- `list_all_tools()` awaits each MCP client
- `AsyncManagedClient::listed_tools()` can await the client startup future directly when there is no startup snapshot available
- there is already a unit test named `list_all_tools_blocks_while_client_is_pending_without_startup_snapshot`
That makes me suspect a resumed turn can stall indefinitely if one MCP client startup future never resolves, even though the helper process itself has already been spawned.
The other clue is that `exec` waits for events with no obvious overall timeout, so if startup gets wedged before the resumed turn really begins, the CLI looks completely silent from the outside.
I intentionally redacted private repo paths, prompt text, session ids, and any local secrets from this report. If useful, I can follow up with sanitized logs or help test a patch with extra instrumentation around MCP initialize / tools listing during `resume`.
If that issue matches your problem, consider adding a
If it is not the same issue, try searching the existing GitHub issues for a closer match. If you cannot find one, then open a new issue with as much detail as possible.
reaction on the GitHub issue page itself, not just on the forum topic, as reactions on GitHub help the developers gauge impact and prioritize work.