Codex Desktop hangs at 100% CPU before window creation when ChatGPT auth.json is present

Open 💬 1 comment Opened Jun 11, 2026 by KimGSeok

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-show log 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_type parse 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 / bundle 3722.

What steps can reproduce the bug?

  1. Use Codex Desktop on macOS with a ChatGPT signed-in auth state present at ~/.codex/auth.json.
  2. Let the Mac sleep and wake it, or quit and relaunch Codex Desktop with that auth file present.
  3. Observe Codex Desktop hanging with a spinner / no usable window.
  4. Check process CPU usage. The main /Applications/Codex.app/Contents/MacOS/Codex process is near 100% CPU.
  5. Check the desktop log. It stops after app_server_connection.state_changed ... next=connected.
  6. Move ~/.codex/auth.json aside.
  7. Relaunch Codex Desktop.
  8. 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.json present: startup hangs and CPU spikes
  • with ~/.codex/auth.json absent: 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

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗