macOS desktop 26.803.41515 beach-balls before thread/list with clean profile and zero sessions

Open 💬 1 comment Opened Aug 12, 2026 by ericosiu
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

ChatGPT/Codex Desktop on macOS becomes permanently unresponsive (spinning beach ball) shortly after launch. The bundled CLI works normally and can list/resume existing sessions, but the desktop UI never populates chats and remains frozen indefinitely.

The problem persists with an effectively clean desktop profile and zero session transcripts, which rules out a single corrupted or oversized rollout as the sole cause.

Environment

  • Device: Mac Studio
  • macOS: 15.5 (24F74)
  • ChatGPT/Codex Desktop: 26.803.41515
  • Build: 6321
  • Bundle ID: com.openai.codex
  • Subscription: ChatGPT Pro
  • Web ChatGPT: works normally
  • Codex CLI: works normally; previous sessions can be listed and resumed

User-visible behavior

  1. Launch ChatGPT Desktop and switch to Codex.
  2. Projects may appear, but every project shows No chats.
  3. The main pane displays a spinner.
  4. The app beach-balls and remains unresponsive for more than an hour.
  5. Remote/mobile access initially works only in a limited fashion and then becomes degraded while the host UI is frozen.

Crash diagnostic

A macOS diagnostic report contains:

exception: EXC_BREAKPOINT
signal: SIGTRAP
termination: Trace/BPT trap: 5
bundleID: com.openai.codex
app_version: 26.803.41515
build_version: 6321

App-server evidence

The local app-server starts and initializes successfully:

  • connection reaches connected
  • authentication succeeds
  • config/read, account/read, and other startup requests complete quickly
  • no SQLite errors or connection failures appear
  • the UI never sends thread/list

The last observed successful startup request is plugin/installed. After that, the renderer stops making useful progress.

Process sample

A 10-second macOS sample shows the process spending effectively the entire sample in the Codex Framework's V8/Node path, including:

v8::ScriptCompiler::CompileModule
v8::Message::GetStackTrace
v8impl::Reference::InvokeFinalizerFromGC
v8::ValueSerializer::WriteValue
node::InternalMakeCallback
node::PrincipalRealm::enhance_fatal_stack_before_inspector

This looks like a V8 serialization/GC/compilation loop rather than a backend, database, or network wait.

Troubleshooting already performed

The issue persists after all of the following:

  • rebooting macOS
  • deleting and reinstalling the latest desktop app
  • confirming chatgpt.com works normally
  • resetting Application Support/com.openai.chat
  • resetting Application Support/com.openai.codex
  • resetting Codex/ChatGPT WebKit, HTTP storage, caches, and preferences
  • resetting Application Support/Codex
  • moving/rebuilding ~/.codex/state*.sqlite*
  • disabling GPU and GPU compositing at launch
  • quarantining plugin/config/browser/computer-use state
  • stopping stale ChatGPT Helper, app-server, and node_repl processes
  • quarantining multiple inactive rollouts larger than 100 MB
  • finally moving the entire ~/.codex/sessions directory aside, creating an empty sessions directory, rebuilding state, and launching with zero sessions

Even with zero sessions and quarantined plugin/config state, the desktop UI still beach-balls. Restoring the sessions makes them usable from codex resume --all, confirming the underlying transcripts and CLI are functional.

Expected behavior

The desktop UI should initialize, request the thread list, and remain responsive. If renderer initialization or persisted state fails, the app should surface a recoverable error rather than entering a permanent CPU-bound V8 loop.

Additional context

This appears related to the existing macOS CrBrowserMain / EXC_BREAKPOINT / V8 renderer issue family, but the clean-profile and zero-session reproduction suggests the current build can fail independently of large individual rollout files.

Full crash/sample files can be provided privately if a maintainer identifies a safe upload path; they may contain local filesystem metadata.

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 16 days ago

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

  • #38037
  • #37493

Powered by Codex Action