Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix codex 0.125.0 (Homebrew cask) hangs on startup on macOS — no TUI, no output, no error [3 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#20025•Fetched 2026-04-29 06:23:38
View on GitHub
Comments
3
Participants
3
Timeline
9
Reactions
0
Author
cossiocossio
Participants
cossiocossioetraut-openaietraut-openaigithub-actions[bot]github-actions[bot]
Timeline (top)
commented ×3labeled ×3cross-referenced ×2unlabeled ×1

After Homebrew auto-bumped the codex cask to 0.125.0 today, running codex with no arguments hangs indefinitely. There is no TUI, no stdout/stderr output, and no error. The process has to be killed manually. Even codex --version hangs, so this is not a TUI-only problem — the process never gets far enough to print its version.

Error Message

and no error. The process has to be killed manually. Even codex --version that never completes, with no timeout or error path. But since `--version`

Root Cause

After Homebrew auto-bumped the codex cask to 0.125.0 today, running codex with no arguments hangs indefinitely. There is no TUI, no stdout/stderr output, and no error. The process has to be killed manually. Even codex --version hangs, so this is not a TUI-only problem — the process never gets far enough to print its version.

RAW_BUFFERClick to expand / collapse

Summary

After Homebrew auto-bumped the codex cask to 0.125.0 today, running codex with no arguments hangs indefinitely. There is no TUI, no stdout/stderr output, and no error. The process has to be killed manually. Even codex --version hangs, so this is not a TUI-only problem — the process never gets far enough to print its version.

Environment

  • codex (Homebrew cask): 0.125.0 (/opt/homebrew/bin/codex → /opt/homebrew/Caskroom/codex/0.125.0/codex-aarch64-apple-darwin)
  • macOS: 26.4.1 (build 25E253), arm64 (Apple Silicon)
  • Codex desktop app also installed at `/Applications/Codex.app`, version bundle 26.422.62136, bundling CLI 0.126.0-alpha.8. The desktop app was running at the time of the hang, with an `app-server` process and an IPC socket at `$TMPDIR/codex-ipc/ipc-502.sock`.

Reproduction

  1. Have the Codex desktop app running (its `app-server` is active and the IPC socket exists in `$TMPDIR/codex-ipc/`).
  2. Run `codex` (no args) from a normal terminal.
  3. Process hangs forever; needs SIGKILL/Ctrl-C to exit.
  4. `codex --version` also hangs (no output before the hang).

What works

  • `/Applications/Codex.app/Contents/Resources/codex --version` (the desktop-app-bundled CLI, 0.126.0-alpha.8) responds immediately.
  • So this appears to be specific to the standalone Homebrew-cask CLI 0.125.0.

Hypothesis

Possibly a version mismatch between the standalone CLI (0.125.0) and the desktop app's app-server / IPC socket (0.126.0-alpha.8) leads to a handshake that never completes, with no timeout or error path. But since `--version` hangs too, the issue is hit very early in startup — before any TUI work — so the cause may be more general (e.g. blocking IPC/auth/marketplace probe with no timeout).

Notes

  • Binary is signed (TeamID `2DC432GLL2`). Has the usual `com.apple.quarantine` xattr from a Homebrew cask install — Gatekeeper would surface a dialog, not silently hang, so I don't think that's it.
  • `~/.codex/config.toml` contains a couple of values that look non-standard (`model = "gpt-5.5"`, `model_reasoning_effort = "xhigh"`, `personality = "pragmatic"`); willing to retest with those removed if it would help triage.

extent analysis

TL;DR

The issue can likely be resolved by downgrading the codex cask to a version compatible with the desktop app's app-server or by removing the IPC socket to prevent the handshake issue.

Guidance

  • Verify if the issue persists when the Codex desktop app is not running, to confirm the hypothesis of a version mismatch causing the handshake issue.
  • Try removing the IPC socket at $TMPDIR/codex-ipc/ipc-502.sock to see if it resolves the issue, as this might prevent the blocking IPC call.
  • Consider downgrading the codex cask to a version known to be compatible with the desktop app's app-server, such as the version bundled with the desktop app (0.126.0-alpha.8).
  • Test the codex command with the --version flag after making these changes to verify if the issue is resolved.

Example

No code snippet is provided as the issue seems to be related to version compatibility and IPC socket interaction rather than a code-level problem.

Notes

The issue might be specific to the interaction between the standalone CLI and the desktop app's app-server, and resolving the version mismatch or removing the IPC socket might not be a permanent fix but rather a workaround.

Recommendation

Apply workaround: Remove the IPC socket to prevent the handshake issue, as this is a non-invasive change that can help verify the hypothesis without modifying the installed versions of codex.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#prompt formatting#chain error#conversation history

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix codex 0.125.0 (Homebrew cask) hangs on startup on macOS — no TUI, no output, no error [3 comments, 3 participants]