›_ Codex Issues
Codex Issues / #26507

Mac desktop app freezes on launch (blank screen, high CPU) — corrupted ~/.codex session; fixed by moving the folder aside

Open 💬 3 comments Opened Jun 5, 2026 by danbenmoshe
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.602.30954 • Released Jun 4, 2026

What subscription do you have?

ChatGPT Plus

What platform is your computer?

_No response_

What issue are you seeing?

Environment

  • Codex desktop app version: 26.601.21317
  • macOS: Apple M3 Max
  • Mac: apple silicon

Summary
The desktop app froze permanently on launch — blank/translucent window
showing only the Codex logo, no sign-in screen, no UI. Activity Monitor
showed CPU climbing and staying elevated the whole time the app was open,
suggesting it was stuck processing something on startup rather than idle.

How it started
It began mid-session in a long conversation: the input field froze and I
could no longer click, type, or switch conversations. I quit and reopened;
a new conversation worked briefly, then stalled the same way. After a couple
of cycles, the app would no longer get past the loading screen on launch.

Possibly relevant: around this time I deleted a folder in ~/Documents that
Codex had been using as a working directory for the stuck conversation. The
freeze may be the app failing to handle an active session whose working
folder no longer exists.

What did NOT fix it

  • Quitting and relaunching
  • Restarting / shutting down the Mac
  • Confirming the app was on the latest version
  • Logging out
  • Clearing ~/Library/Application Support/Codex (fresh profile still froze)

What DID fix it
Renaming ~/.codex to ~/.codex.OLD and relaunching. The app then loaded the
normal sign-in screen and worked. This points to a corrupted session/state
file in ~/.codex that the app chokes on at startup instead of skipping or
recovering gracefully.

Suggested fix
The app should fail gracefully on a corrupt/oversized session file — skip it
and still render the UI — rather than hanging the whole app on launch.

What steps can reproduce the bug?

see "What issue are you seeing"

How it started
It began mid-session in a long conversation: the input field froze and I
could no longer click, type, or switch conversations. I quit and reopened;
a new conversation worked briefly, then stalled the same way. After a couple
of cycles, the app would no longer get past the loading screen on launch.

Possibly relevant: around this time I deleted a folder in ~/Documents that
Codex had been using as a working directory for the stuck conversation. The
freeze may be the app failing to handle an active session whose working
folder no longer exists.

What is the expected behavior?

see "What issue are you seeing"

Summary
The desktop app froze permanently on launch — blank/translucent window
showing only the Codex logo, no sign-in screen, no UI. Activity Monitor
showed CPU climbing and staying elevated the whole time the app was open,
suggesting it was stuck processing something on startup rather than idle.

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #26161
  • #25163
  • #25430
  • #25251
  • #25215

Powered by Codex Action

angelol · 2 months ago

Why renaming ~/.codex fixes this, and a less-destructive version

I traced this on macOS 26.5.1 / Codex 26.616.32156. The freeze/wedge is the syspolicyd FD-exhaustion bug tracked in #16767/#25882: at startup, app-server reconciles your accumulated ~/.codex history (the state_5.sqlite thread table + rollout .jsonl files) and spawns a flood of short-lived Resources/codex children that fail Gatekeeper/qtn_proc, leaking syspolicyd file descriptors until every app launch is denied. Renaming ~/.codex works because it removes that accumulated history, so the startup reconciliation has ~nothing to iterate (I confirmed: empty ~/.codex → no storm; ~3,900 accumulated threads → storm).

You don't have to discard everything, but it has to be the rollout files, not just the DB — pruning state_5.sqlite alone didn't help in my testing because it repopulates from the .jsonl files. What worked conceptually: archive the old sessions/ + archived_sessions/ rollout files aside (keep only your most recent handful) and let Codex rebuild a small state_5.sqlite. The threshold is low (it still stormed at ~100 threads), so keep the kept set small (last day or so). Your .jsonl files are never lost — just moved aside and restorable.

Immediate recovery when it's already wedged: sudo killall syspolicyd (no reboot needed).

shleder · 14 days ago

Renaming ~/.codex to ~/.codex.OLD immediately restoring startup is a useful isolation result: some persisted local state triggers the blank/high-CPU launch loop, while the old data may still be available for diagnosis.

Codex Rescue is local-first and does not modify the source rollout or state directory. It cannot determine from the report alone whether the trigger is a rollout, database, or missing cwd, so I’m trying to validate whether its current diagnostic boundary catches this safely.

If you still have ~/.codex.OLD, could you test against a copy/local Codex home and run:

pipx install codex-rescue==0.1.0a3
codex-rescue sessions
codex-rescue doctor --latest

Sanitized output only—no raw state files, databases, prompts, paths, or secrets.

https://github.com/shleder/codex-rescue