Codex Desktop hangs at 100% CPU before window creation when ChatGPT auth.json is present
What version of the Codex App are you using?
Codex Desktop 26.608.12217
Bundle version: 3722
Bundle identifier: com.openai.codex
What subscription do you have?
Unknown / ChatGPT sign-in. The issue is triggered when Codex Desktop has a ChatGPT-authenticated ~/.codex/auth.json file.
What platform is your computer?
Darwin 25.1.0 arm64 arm
macOS 26.1 (25B78)
What issue are you seeing?
Codex Desktop can hang before the primary window is created when a signed-in ChatGPT auth state exists at ~/.codex/auth.json.
After waking the Mac from sleep, Codex Desktop became unresponsive with a spinner. The main process:
/Applications/Codex.app/Contents/MacOS/Codex
was using approximately 100% CPU.
Killing and relaunching Codex Desktop while ~/.codex/auth.json was present reproduced the issue immediately:
- the main Codex Desktop process went to about 98-100% CPU
- no usable window appeared
- the desktop log stopped immediately after the app-server connection reached
next=connected - there were no subsequent
[IpcRouter]or[window-manager] window ready-to-showlog lines
Representative failing log stopping point:
[AppServerConnection] app_server_connection.state_changed ... next=connected
If I move ~/.codex/auth.json out of the way and relaunch Codex Desktop, the app starts normally in a signed-out state.
Representative working launch:
[AppServerConnection] app_server_connection.state_changed ... next=connected
[remote-connections/window-context] refresh_local_remote_control_client_id_failed ... "Sign in to ChatGPT in Codex Desktop to check remote control authorization."
[IpcRouter] I am the router
[window-manager] window ready-to-show appearance=primary ...
[window-manager] window main frame finished load appearance=primary ...
This looks related to #26750, but the failure mode is earlier and more severe:
- #26750 reports a white/black unresponsive renderer after login with a Statsig
user.custom.workspace_typeparse error. - This issue blocks startup before the primary window is created and pegs the main desktop process at 100% CPU.
- This reproduces on a newer Codex Desktop build,
26.608.12217/ bundle3722.
What steps can reproduce the bug?
- Use Codex Desktop on macOS with a ChatGPT signed-in auth state present at
~/.codex/auth.json. - Let the Mac sleep and wake it, or quit and relaunch Codex Desktop with that auth file present.
- Observe Codex Desktop hanging with a spinner / no usable window.
- Check process CPU usage. The main
/Applications/Codex.app/Contents/MacOS/Codexprocess is near 100% CPU. - Check the desktop log. It stops after
app_server_connection.state_changed ... next=connected. - Move
~/.codex/auth.jsonaside. - Relaunch Codex Desktop.
- Observe that Codex Desktop starts normally in a signed-out state and reaches
[window-manager] window ready-to-show.
I reproduced this multiple times:
- with
~/.codex/auth.jsonpresent: startup hangs and CPU spikes - with
~/.codex/auth.jsonabsent: startup proceeds normally
The auth file was not deleted for testing; it was moved aside/backed up.
What is the expected behavior?
Codex Desktop should not spin at 100% CPU or block window creation because of ChatGPT desktop auth state.
If the saved auth state is stale, malformed, incompatible with account-side data, or needs refresh, the app should still create the window and prompt for re-authentication or recover gracefully.
Additional information
I captured a macOS sample of the hung process. The hot path was in the Electron/Node/V8 main-thread area, including frames around:
ChromeMain
v8::internal::ThreadIsolation::SplitJitPage
uv_run
with many JS/JIT frames below it.
The local workaround is to move ~/.codex/auth.json aside before launching Codex Desktop. That makes the app usable in a signed-out state, but signing in again may regenerate auth.json and reintroduce the hang on a later restart or sleep/wake cycle.
Related issue: #26750
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗