ChatGPT desktop crashes when opening a long local Codex thread #44256

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Sep 9, 2026
2. github-actions commented on Sep 9, 2026

   

   github-actionsBot

   on Sep 9, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Desktop app 26.901.41600: repeated macOS SIGTRAP in CrBrowserMain, possible read_thread correlation #43089

   Powered by Codex Action
3. langaz4a2c commented on Sep 10, 2026

   

   langaz4a2c

   on Sep 10, 2026

   Author

   More actions

   Additional evidence from further reproduction:

   • The newly created lightweight replacement thread also crashes the desktop app when clicked.
   • During diagnosis, the currently open troubleshooting thread also crashed while reading the replacement thread state.
   • A new macOS crash report was generated at 2026-09-10 15:30:29 +0800. It has the same signature as the earlier crashes: EXC_BREAKPOINT / SIGTRAP on faulting thread 0 (CrBrowserMain) with the same Chromium/V8 top frames.
   • Two other repeated crashes occurred at 03:06:48 and 03:07:47 with the same signature.
   • The replacement thread is lightweight but was associated with the same local project and later showed status notLoaded. This suggests the issue is not limited to rendering an oversized original thread.
   • The possible read_thread correlation mentioned in Desktop app 26.901.41600: repeated macOS SIGTRAP in CrBrowserMain, possible read_thread correlation #43089 may be relevant.

   No private thread transcript, spreadsheet data, or crash log attachment is included.
4. rlgus1985-glitch commented on Sep 25, 2026

   

   rlgus1985-glitch

   on Sep 25, 2026

   More actions

   Additional reproducible macOS case (2026-09-26 KST): clicking one pinned, image-heavy local Codex chat makes the ChatGPT desktop app flicker, return to the main view, or restart; other chats remain usable. The affected transcript is 5,674,430,263 bytes (82,018 JSONL lines), with thousands of inline data:image / image_url occurrences. I am not attaching the private transcript, images, or raw logs.

   Environment: ChatGPT desktop 26.924.20706 (bundle build 11431), macOS 27.0 (26A428), Apple Silicon. macOS recorded two ChatGPT-process crashes today, 00:11:42 and 06:45:08 KST. Both are EXC_BREAKPOINT / SIGTRAP on the main thread, termination signal 5; these are app crashes, not a demonstrated system-wide OOM. The transcript's modification time matches the latter crash. Image count and size strongly suggest oversized history is a trigger, but I cannot attribute the native assertion to a specific image or code path without vendor symbols.

   The user needs this chat for ongoing game work. We preserved the original byte-for-byte in a private, independent local clone and handed off to a smaller new chat using source-file paths and SHA-256s, leaving the original chat and assets untouched. Please make opening large histories bounded/lazy, avoid hydrating old inline image payloads into main-process/renderer IPC, keep the original conversation navigable, and contain a single-thread load failure so the whole app does not restart. This appears closely related to #28531; an app-level migration/recovery path is needed rather than requiring users to abandon the old thread.
5. huangjun919 commented on Oct 3, 2026

   

   huangjun919

   on Oct 3, 2026 – with ChatGPT Codex Connector

   Last edited by huangjun919

   More actions

   Additional macOS reproduction after updating to the current production build on 2026-10-03 (Asia/Shanghai). There is also a second UI-reset symptom at the View usage entry point, described separately below.

   Environment

   • ChatGPT/Codex desktop app: 26.930.31730, build 12947 (production; built-in update check reports up to date).
   • macOS 26.6.2 (25G83), Apple Silicon / arm64.
   • Chromium renderer version recorded by Crashpad: 154.0.8037.98.

   Long local chat: reproduction and result

   1. Update the desktop app to the version above.
   2. Open one existing, very long local Codex chat under a local project from the sidebar.
   3. The chat starts loading, then the UI resets to the main/home view. The user reports this began only after the 2026-10-03 update; the chat opened normally before it.

   The affected local JSONL transcript is 4,866,729,398 bytes. The chat remains idle and its latest turn can still be read through the app backend, so there is no evidence of lost conversation data. I have not established whether other chats are affected.

   Correlated diagnostics for the long-chat attempt

   • At 15:52:18 local time, the app log records a successful thread/read response followed by repeated thread/items/list responses for the affected chat.
   • At 15:52:20, thread_navigation and thread_hydration report outcome=success, while older history pages continue loading.
   • Crashpad recorded capture_kind=crash, ptype=renderer at 15:52:25 (sidecar 21a20b82-3ed9-4046-8555-a4b547f65b33). At 15:52:36, the app log requests codex-home, matching the visible return to the main view.
   • A second attempt produced another renderer crash at 15:57:53 (sidecar 47209f3c-5bed-45ee-bf44-73682fe1cf58), after another successful navigation/hydration and history-loading sequence.
   • No matching macOS DiagnosticReports entry for the main app process was found in the inspected period. The demonstrated failure is a renderer crash/reload, not a confirmed main-process crash.

   Additional symptom: View usage

   The user reports that clicking View usage has also returned the desktop UI to the main/home view twice after the same update. I have not yet correlated those two occurrences with an independent Crashpad record or a specific log event, so I cannot establish that they share the long-chat failure's root cause. Please test this entry point separately in build 12947.

   Please investigate bounded/lazy loading of very large chat histories and provide a supported recovery path that preserves the original chat. The trigger and exact root cause remain unproven. No private transcript, raw logs, local paths, chat ID, or creative content are included in this public comment.

   Third confirmed reproduction (2026-10-03 16:19 Asia/Shanghai)

   The user opened the same affected local chat again. At 16:18:57, the desktop log records thread/read and a burst of thread/items/list responses; at 16:19:03, Crashpad recorded another capture_kind=crash, ptype=renderer (sidecar 3895af1f-1683-4f2d-8839-c23ca897dcba). A React root render request appears at 16:19:08, followed by codex-home requests at 16:19:10. The ChatGPT main process remained running. This is a third same-pattern renderer crash after opening the chat, strengthening the reproduction; it still does not identify the underlying code defect.