›_ Codex Issues
Codex Issues / #38037

Unable to use ChatGPT app on my laptop

Open 💬 2 comments Opened Aug 11, 2026 by CrossPeakZane
💡 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)?

26.803.41515 (6321)

What subscription do you have?

Pro

What platform is your computer?

Mac - Darwin 25.5.0 arm64 arm

What issue are you seeing?

Analysis from Claude Code

ChatGPT Desktop Crash Investigation — Summary

Date: August 9, 2026
Machine: Zane-Perry-MacBook-Pro (Mac16,1, macOS 26.5.2)

The Problem

ChatGPT desktop app (version 26.803.41515) crashes within ~5 seconds of every launch. Cannot be opened at all.

Root Cause

This is a bug in OpenAI's own shipped code, not related to Claude Desktop, the Brain (MCP), or anything on this machine that we control.

  • Crash type: EXC_BREAKPOINT (SIGTRAP) — a deliberate breakpoint instruction (brk 0) hit inside OpenAI's own binary.
  • Where: Inside Codex Framework.framework (version 151.0.7922.76), OpenAI's bundled Chromium/V8/Node engine — specifically in node::StringDecoder::DecodeData → v8::Isolate::Enter().
  • Confirmed identical across 3 separate crash attempts, including after:
  • A full uninstall/reinstall (same build downloaded each time — no update available)
  • Clearing ChatGPT's cache (~/Library/Caches/com.openai.chat)
  • Wiping the entire app data directory (~/Library/Application Support/com.openai.codex) and launching with a completely fresh profile
  • Since it crashes identically even on a brand-new empty profile, this is not a corrupted local file, config, or account state — it's a defect baked into the binary itself on this OS/hardware combination (macOS 26.5.2, Apple M4 / Mac16,1).

What Was Ruled Out

  • Claude Brain / MCP: Checked the actual supervisor code (brain-mcp/supervisor.mjs, src/infra.js). The brain's automation only ever starts brain services when Claude Desktop is running — it never automatically closes or kills ChatGPT. A closeChatGptDesktop() function does exist in the code, but it only fires from a manual "Close Claude and Brain" action, never automatically.
  • Shared Codex config file (~/.codex/config.toml, used by both ChatGPT Desktop and Codex CLI): inspected and found well-formed, no duplicate/corrupted entries (a similar-sounding issue happened on the Windows machine on Aug 7, but was unrelated and already fixed in a prior brain version).
  • A misfiring scheduled brain job ("Daily Brain Issues Improvement") was found firing repeatedly around the same time as the first crash — investigated and ruled out; it's a text-only git/GitHub task with no interaction with ChatGPT or its files. It's a separate bug worth fixing on its own, unrelated to this crash.
  • No silent background update occurred between "worked fine this morning" and "crashing tonight" — same build the whole time.

This Matches a Known Public Issue

The same crash signature is reported by other users on GitHub:

Context: OpenAI merged Codex into the ChatGPT desktop app around July 9, 2026 in a rollout widely described as rough (9to5Mac called it "inexplicably botched"), with a partial walk-back about a week later. This crash is part of the fallout.

What Was NOT Fixable Locally

Every local remedy was tried and failed to change the outcome:

  1. Uninstall / reinstall — no effect (same build)
  2. Clear cache — no effect
  3. Wipe entire app data directory to a fresh profile — no effect, identical crash

Recommended Next Steps (Zane's call)

  1. Downgrade to an older ChatGPT build if one is available, until OpenAI patches this.
  2. File/comment on the OpenAI GitHub issue with this crash log — adds signal for a fix.
  3. Wait for OpenAI's next release — this is their bug to fix, not something further local troubleshooting can resolve.

Side Note

A backup of the original ChatGPT app data was made before the data-wipe test:
~/Library/Application Support/com.openai.codex.bak-1786328797
A fresh (also-crashing) copy was recreated by the app on relaunch at ~/Library/Application Support/com.openai.codex. To restore your original chat history/settings once ChatGPT is working again:

rm -rf ~/Library/Application\ Support/com.openai.codex
mv ~/Library/Application\ Support/com.openai.codex.bak-1786328797 ~/Library/Application\ Support/com.openai.codex

What steps can reproduce the bug?

Open the app, wait 5 seconds for it to crash

What is the expected behavior?

Not to crash

Additional information

This is preventing me from using my subscription. Please direct me towards where to get a refund for wasted time while your team works to resolve this issue.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 16 days ago

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

  • #37493

Powered by Codex Action

ChristianHed · 11 days ago

Same crash, still present two builds later — adding a second data point on different hardware and a much older macOS, plus some isolation work that may help narrow it down.

Environment

| | |
|---|---|
| App | 26.810.52044 (build 6662) |
| Codex Framework | 151.0.7922.137 |
| Machine | MacBook Pro 18,3 — Apple M1 Pro, 32 GB |
| macOS | 14.8.2 (23J126) |
| Last known good | 26.727.51351 (build 6119) |
| SIP | enabled |
| Other | Tailscale VPN active (utun5) |

Note this is macOS 14 on M1 Pro, versus macOS 26.5.2 on M4 in the original report — so it is not tied to Tahoe or to Apple silicon generation.

Timeline

The previous build ran continuously and without a single issue for ~36 hours. Then Sparkle auto-updated it, and it has never started successfully since:

09:53:43Z  last normal activity, log reports release=26.727.51351
09:54:14Z  [sparkle] Production Sparkle update event action=install_started currentBuildNumber=6119
09:54:34Z  first crash on 6662

8 consecutive crashes, 0 successful launches. Crash is deterministic at ~10 s after launch (the original report says ~5 s; possibly load-dependent).

Crash signature

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x0000000118c8132c
Crashed Thread:  0  CrBrowserMain  Dispatch queue: com.apple.main-thread

Top frames (nearest-symbol names, clearly mis-attributed):

0  Codex Framework  ares_llist_replace_destructor + 21628
1  Codex Framework  ares_llist_replace_destructor + 21520
2  Codex Framework  reading_mode$cxxbridge1$194$parse_distilled_html + 13224316
3  Codex Framework  reading_mode$cxxbridge1$194$parse_distilled_html + 13224196
4  Codex Framework  v8::CpuProfileNode::GetDeoptInfos() const + 42584
5  Codex Framework  v8_simulator_probe_memory_continuation + 2380
6  Codex Framework  v8::String::NewFromUtf8(...) + 328
7  Codex Framework  node::StringDecoder::DecodeData(...) + 1028
8  Codex Framework  node::StringDecoder::DecodeData(...) + 564
9  Codex Framework  _register_external_reference_string_decoder(...) + 916
...
20 Codex Framework  node::InternalCallbackScope::Close() + 400
21 Codex Framework  node::fs::FSReqPromise<...>::SelfSize() const + 636
22 Codex Framework  node::fs::AfterInteger(uv_fs_s*) + 204
23 Codex Framework  node::MakeLibuvRequestCallback<uv_fs_s, void (*)(uv_fs_s*)>::Wrapper + 204
24 Codex Framework  uv__work_done + 172
27 Codex Framework  uv_run + 972

I can confirm the StringDecoder::DecodeData frames mentioned in the original report. What the fuller stack adds: the fatal error is raised from the JS completion callback of an async filesystem request (uv_run → uv__work_done → node::fs::AfterInteger → JS), on the browser main thread. A Node worker thread named git is alive at crash time.

Last error the app logs before dying, on every single launch:

error [electron-message-handler] Request failed method=fs/readFile
  error={"code":-32603,"message":"No such file or directory (os error 2)"}
  source=filesystem

Startup otherwise completes fully — both windows finish loading, chatgpt-account-lookup reports result=succeeded — then ~3 s of complete log silence, then the crash. So this is not a startup-path failure; something fires shortly after the app is nominally ready.

This looks distinct from the computer-use / sky.node thread-exhaustion OOM report (crash after 70–114 s with runaway thread and heap growth). This one is a hard trap at a fixed point with no memory growth involved.

Isolation — what has been ruled out

| Hypothesis | Test | Result |
|---|---|---|
| Corrupt / partial Sparkle install | codesign --verify --deep --strict + spctl -a -vv | Passes. Notarized, Developer ID: OpenAI OpCo, LLC (2DC432GLL2). Bundle intact. |
| Corrupt local app state | Removed state_5.sqlite{,-shm,-wal}, external_agent_session_imports.json and the app's Saved Application State, relaunched | Identical crash — same faulting address offset, byte for byte |
| Bad config.toml (incl. one MCP server whose command points at an unmounted DMG volume, and a stale BROWSER_USE_CODEX_APP_VERSION = "26.727.51351") | Removed ~/.codex/config.toml entirely, relaunched | Still crashes (survived to ~11 s instead of ~10 s) |
| Fixed in a newer build | Re-downloaded ChatGPT.dmg from openai.com and read its Info.plist | DMG contains the identical build 6662 — no newer build is published |

So it reproduces with empty app state and no configuration file at all, which matches the original reporter's finding that uninstall/reinstall/fresh profile changes nothing.

Downgrade is not possible

Worth flagging, because it turns this from an annoyance into a hard block: there is no way back.

  • OpenAI does not publish previous builds.
  • Sparkle keeps no local copy of the build it replaced — ~/Library/Caches/com.openai.codex/org.sparkle-project.Sparkle/PersistentDownloads is empty.
  • No copy of the old app remained anywhere on disk (checked via mdfind), and the only local APFS snapshots are com.apple.os.update-* system snapshots, which do not contain third-party apps.

An auto-update with no rollback path, shipping a build that traps on launch, leaves the app permanently unusable.

Requests

  1. Please make 26.727.51351 (or any pre-26.810 build) downloadable as a stopgap.
  2. The async-fs completion callback on the browser main process, firing a few seconds after startup completes, looks like the place to look — it is fully deterministic there with empty state and no config.

Happy to supply full .ips crash reports (8 of them) or run any specific test on 14.8.2 / M1 Pro if that helps.