›_ Codex Issues
Codex Issues / #34556

macOS: Opening any local project consistently crashes the desktop app (EXC_BREAKPOINT / SIGTRAP)

Open 💬 2 comments Opened Jul 21, 2026 by nemo4444

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

26.715.61943 (5628)

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

The ChatGPT desktop application crashes every time I open any local project.

The issue is 100% reproducible.

The project opens briefly, conversation history becomes visible, and then the application crashes before I can type anything.

The issue affects every local project I have tested.

The problem persists in both build 5551 and build 5628.

What steps can reproduce the bug?

  1. Launch the ChatGPT desktop app.
  1. Open any existing local project.
  1. Wait a few seconds.

The project opens briefly, conversation history appears, and then the application crashes before any interaction is possible.

This happens every time.

crashlog_26.715.61943_build5628_macOS26.5.2.txt

crashlog_26.715.31925_build5551_macOS26.5.2.txt

What is the expected behavior?

Opening a local project should not crash the application.

The project should remain open and fully usable.

Additional information

Environment

  • MacBook Air M4
  • macOS 26.5.2 (25F84)
  • ChatGPT Desktop
  • Bundle identifier: com.openai.codex

Affected versions

  • 26.715.31925 (build 5551)
  • 26.715.61943 (build 5628)

The crash occurs approximately 20 seconds after launching the application, but only after opening a local project.

Troubleshooting already performed

  • reinstalled the application
  • removed Application Support data
  • removed application caches
  • reset local application state

The problem persists.

Crash signature

  • EXC_BREAKPOINT (SIGTRAP)
  • Thread: CrBrowserMain

The stack consistently includes:

  • node::fs::FSReqCallback::Resolve
  • node::fs::AfterInteger

before returning through V8.

This appears to affect all local projects rather than one corrupted project.

Possibly related to #32676 because the native crash signature is similar, but the reproduction trigger is different: in my case, it occurs consistently when opening any local project, immediately after its conversation history becomes visible.

View original on GitHub ↗

2 Comments

nemo4444 · 1 month ago

The issue is still reproducible in 26.721.41059 (build 5848) on macOS 26.5.2.

The behavior is unchanged:

  1. Open any existing local project.
  2. Conversation history becomes visible.
  3. The app crashes before any interaction is possible.

The latest crash report again shows:

  • EXC_BREAKPOINT (SIGTRAP)
  • faulting thread: CrBrowserMain
  • node::fs::FSReqCallback::Resolve
  • node::fs::AfterInteger

This now reproduces across at least three builds:

  • 26.715.31925 (5551)
  • 26.715.61943 (5628)
  • 26.721.41059 (5848)

The problem therefore remains unresolved after multiple application updates.

Latest crash report

crashlog_26.721.41059_build5848_macOS26.5.2.txt

ivogundlach · 19 days ago

Current-build reproduction with cancellation timing

I reproduced the same native Codex Desktop crash three times on August 9, 2026.

Environment:

  • Codex App 26.803.41515, build 6321
  • macOS 27.0, build 26A5388g
  • Apple Silicon, Darwin 27.0.0 arm64 arm

All three incidents were full main-process crashes with the same signature:

  • EXC_BREAKPOINT / SIGTRAP
  • faulting thread: CrBrowserMain
  • identical normalized framework offset: 0x4471398
  • stack includes node::fs::FSReqCallback::Resolve and node::fs::AfterNoArgs before returning through V8

The repeatable application event sequence was:

  1. Open or switch to an existing local task.
  2. Task ownership discovery times out after five seconds.
  3. The hidden avatarOverlay renderer logs Conversation state not found for that task.
  4. thread/resume succeeds.
  5. The app crashes approximately 1.5 seconds later.

The third incident narrowed the trigger. Only two turns were running, and they had remained stable for several minutes. I opened another existing task but did not start a new turn in it. The restore sequence above completed and the entire app crashed.

OpenCodex was enabled during all three incidents through a local openai_base_url proxy. Its usage log recorded at least one HTTP 499 client-cancellation event 2.0 to 2.35 seconds before each crash. This may be a timing trigger or amplifier, but I am not claiming that OpenCodex is the root cause. It runs as a separate process and is not loaded into the ChatGPT process. The Codex app should handle request cancellation and task restoration without terminating its main process.

Expected behavior: switching to another task while two turns are active should restore that task without crashing. A cancelled provider request should be isolated to that request.

I can provide the three full macOS crash reports privately. I have not attached them publicly because they contain machine and local-environment identifiers.