Repository navigation
Desktop app 26.901.41600: repeated macOS SIGTRAP in CrBrowserMain, possible read_thread correlation #43089
Description
Summary
The Codex/ChatGPT desktop app repeatedly crashes in its main process on macOS. Three local macOS crash reports show the same top five framework-relative frame offsets in the same app build. The latest crash occurred immediately after a successful read_thread response; this is a temporal correlation, not a confirmed root cause.
Environment
- App process: ChatGPT; bundle identifier: com.openai.codex
- App version: 26.901.41600 (7982)
- Codex Framework version: 152.0.7977.64
- macOS: 26.2 (25C56)
- Hardware model: Mac14,7; ARM-64 native
- System Integrity Protection: enabled
Actual behavior / frequency
The entire foreground desktop app terminates repeatedly. Three crashes were recorded on 2026-09-05 at 19:47:01, 19:50:06, and 19:55:21 UTC. The latest process had been running for approximately four minutes.
All three reports have EXC_BREAKPOINT (SIGTRAP), SIGNAL code 5, with the same top five image-relative offsets:
| Frame | Codex Framework image offset (decimal) |
|---|---|
| 0 | 74333180 |
| 1 | 74333072 |
| 2 | 99390932 |
| 3 | 99390812 |
| 4 | 1098888 |
Crash signature
Triggered thread: 0, CrBrowserMain, com.apple.main-thread.
Top frames as reported by macOS (symbols appear incomplete; large symbol offsets should not be treated as authoritative function attribution):
0 Codex Framework ares_llist_replace_destructor + 21548
1 Codex Framework ares_llist_replace_destructor + 21440
2 Codex Framework reading_mode$cxxbridge1$197$parse_distilled_html + 15636324
3 Codex Framework reading_mode$cxxbridge1$197$parse_distilled_html + 15636204
4 Codex Framework v8::Context::Enter() + 1496
5 Codex Framework v8::Context::Enter() + 1180
Framework binary UUID: 4c4c4432-5555-3144-a168-6b40e0dc8dcb.
Events immediately before the latest crash
The app log shows read_thread starting at 19:55:19.942 UTC, followed by successful thread/read, thread/turns/list and multiple thread/items/list responses. At 19:55:21.353 UTC, electron-message-handler logged Sending server response with success=true and tool=read_thread. The macOS crash timestamp is 19:55:21.970 UTC, approximately 617 ms later.
Reproduction status
No minimal deterministic reproduction has been established. The observed workflow was reading an existing task's conversation history through the app's read_thread tool. This operation preceded the latest crash; equivalent log correlation for the other two crashes has not been established. Relaunching did not prevent recurrence.
Expected behavior
Reading task history should complete without terminating the desktop app. Any failure should be contained and surfaced as an error.
Diagnostic limits
The reports establish a repeating native main-process crash, but do not identify the failed runtime check or prove memory exhaustion, database corruption, a GPU fault, or a particular feature as the cause. Please symbolicate the matching framework offsets and investigate the read_thread response handling path.
This report contains a sanitized diagnostic summary. Raw app logs, private conversation content, local project paths, and account identifiers are intentionally omitted.
Activity
github-actions commentedon Sep 5, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
tawandakembo commentedon Sep 8, 2026
Additional evidence from a newer macOS desktop build with a closely matching main-process crash signature. This is not a confirmed root-cause match, but appears relevant to this issue.
Environment
com.openai.codex.26.901.51231(build8109).152.0.7977.83.26.5 (25F71)and, after updating,26.6.2 (25G83).Seven matching native crash reports
All seven reports have thread 0 /
CrBrowserMain,EXC_BREAKPOINT,SIGTRAP, termination namespaceSIGNAL, code5. Their first five framework-relative offsets are identical within this build:Reported nearest symbols include
ares_llist_replace_destructor +21580/+21472, followed byreading_mode$cxxbridge1$197$parse_distilled_htmlwith very large offsets, andcppgc::internal::TraceTraitFromInnerAddressImpl::GetTraceDescriptor(void const*) +74628. These are incomplete symbolications, not proof that DNS, HTML parsing or garbage collection is the faulty component. Maintainer symbolication of the exact build is needed.Crash capture times (local UTC+02:00):
Workflow and impact
The app was being used for long-running, image-heavy local tasks, with two existing tasks repeatedly resumed after interruption. Work involved image generation, local image inspection, research and task coordination. Some generated image files completed and survived the interruption even though the corresponding tool-cell handle was lost; manual recovery from saved files was needed before continuing.
In the 2026-09-08 10:24 local crash, a
dynamic_app_tool_thread_read_startedevent occurred about 2.1 seconds before termination. The final logged response was approximately 0.616 seconds before the crash, but the inspected excerpt does not establish that it was the read result. This is a temporal observation, not proof of causation. Other crashes had different final logged operations.This is an observed workload, not a deterministic minimal reproduction. I have not established that
read_thread, concurrent image generation, memory pressure, or a particular image causes these crashes. Separate earlier usage-limit failures are not being counted as native crashes.Expected behavior: a failing task or oversized history/tool result should fail gracefully without terminating the desktop host or disrupting other active tasks. Persisted completed outputs should remain discoverable after restart.
The seven reports establish repeatable native desktop termination across the OS update. They do not establish an OS out-of-memory kill or kernel panic. Raw crash reports, session transcripts, image payloads, device/account identifiers and private project paths are intentionally omitted. This comment contains only the redacted diagnostic fields above.
tmcuh1982 commentedon Sep 12, 2026
Additional confirmation on newer builds 26.908.40834 (8881) and 26.903.71938 (8576), with a closely matching native main-process signature and a precise
read_threadcorrelation in the latest crash.Environment and captured events
ChatGPT, bundlecom.openai.codex.Both reports record
EXC_BREAKPOINT (SIGTRAP), termination namespaceSIGNAL, code5, oncom.apple.main-thread.The user reported two recent app closures. Only one native crash report was found for September 12. The preceding session logged transport shutdown at 15:15:04.861 local time and the next process launched at 15:15:07.9782; those records alone do not prove that earlier closure was another native crash. The September 10 report is separate historical evidence, not being substituted for an unconfirmed second September 12 crash.
Latest crash: immediately after read_thread
The latest process survived approximately 81 seconds after launch. These log timestamps are UTC, with private identifiers omitted and fields shortened:
The successful
read_threadresponse preceded the native crash by approximately 692 ms. The log ends with that response and has no subsequent normal shutdown sequence.The crashing session also recorded 87
ResizeObserver loop completed with undelivered notifications.errors between 13:15:14.676 and 13:16:27.819 UTC. These are accompanying observations, not an established crash cause.Framework offsets for symbolication
Nearest reported symbols in build 8881:
Framework binary UUIDs (binary identifiers, not device identifiers):
4c4c4491-5555-3144-a1da-b3ccedb951004c4c4497-5555-3144-a1cb-b545f5938260The large nearest-symbol offsets are not reliable source-level attribution. The similar signature across different binaries supports investigating this issue, but does not prove identical root cause.
Workflow, impact and limits
This occurred in a long-running, image-heavy local task. Image generation had completed; the agent was looking up earlier export settings through task-history retrieval before starting a requested batch of local image upscaling. The desktop closed and had to be relaunched, interrupting work. Generated PNGs remained on disk.
No deliberate crash reproduction or live history/database modification was attempted. Root cause, memory exhaustion, a GPU fault and a causal relationship with the separately reported history-projection problem (#44609) remain unproven. Please investigate the main-process handling of
read_threadresponses and symbolicate the offsets for these builds. A history-read failure should be contained rather than terminate the desktop host.This comment contains a reviewed diagnostic summary only. Raw logs, transcripts, image data, personal paths, account/device identifiers and task IDs are omitted.
wvs59vyjcm-blip commentedon Sep 16, 2026
Additional reproducible evidence from macOS on 2026-09-16, without private thread content or account identifiers:
mcp__codex_app__read_threadon one long local thread. EventurnLimit: 1, includeOutputs: false, maxOutputCharsPerItem: 200caused the host to exit about five seconds later. The targeted rollout JSONL is approximately 2.97 GB and 199,931 lines.jq -c emptyparsed it successfully, so gross JSON syntax corruption was not found.This supports a reproducible read-thread/large-history correlation, not a proven root cause. Please symbolicate the native assertion and ensure an oversized or otherwise problematic thread read returns an error rather than terminating the entire desktop host. No raw logs, transcript, paths, thread IDs, or private data are attached.
tyrecords1116-ui commentedon Sep 17, 2026
Additional confirmation from a newer macOS desktop build:
Five native crashes were recorded on September 18, 2026 at the following local times (JST, UTC+09:00):
All five macOS crash reports show
EXC_BREAKPOINT,SIGTRAP, and termination reasonTrace/BPT trap: 5.The reproducible trigger is opening one of several specific existing Local tasks from Recents. The app terminates and restarts shortly after the task begins loading. Other Local tasks and projects open normally, so this is not a general startup failure. The affected task cannot remain open long enough to run
/feedbackor choose “share existing session.”The affected local thread ID has been provided separately to OpenAI Support. Raw logs, session transcripts, private conversation content, local paths, and account/device identifiers are intentionally omitted here. Sanitized diagnostic excerpts can be provided through a private/secure channel if needed.
guozhixin340 commentedon Oct 13, 2026
Additional evidence on a newer macOS desktop build, submitted at the affected user's request. This appears related to the read_thread/main-process crash pattern in this issue; a shared root cause is not confirmed.
Environment
com.openai.codex.Observed workflow and impact
The app was coordinating several existing local chats through the official app tools. The user observed the foreground application quitting after cross-chat messages, reopened it, and requested retries; the same type of native crash recurred three times over approximately ten minutes. The message sends returned successful tool receipts. The closer event in the main-process logs is a successful
read_threadserver response immediately before each crash-report capture.No clean-profile minimal reproduction has been established. Further deliberate crash tests have been stopped to avoid interrupting active work.
Three matching native crashes, 2026-10-13
All times in this table are UTC. The crash column is the crash report's capture timestamp, not an independently instrumented fault timestamp.
This is a temporal correlation. It does not establish that
read_threadcaused the crash, nor that the response was completely processed by its recipient.The three native reports agree on:
The first six framework-relative frame offsets, identical in all three reports, are:
These six offsets also match those published for the same app/framework build in #53240. That report captured an explicit V8 Zone OOM message; we did not capture an equivalent assertion/fatal-error message, so we are not claiming that its cause is established on this machine. Many nearest-exported-symbol displacements are large and do not reliably identify the actual source functions.
Other evidence and limits
ResizeObserver loop completed with undelivered notificationsoccurs near all three incidents, but also occurs in a subsequent non-crashed session. Its causal role is unproven.asiorlastExceptionBacktracefields.Could maintainers symbolicate these framework offsets and investigate handling/serialization of cross-chat history responses on this build? A supported workaround or a confirmed fixed build that preserves existing chats and projects would help.
Privacy
Only a technical summary is included here. Raw logs, conversation contents, project names, personal filesystem paths, thread/account/device identifiers, and credentials are omitted. If further artifacts are needed, please provide an official private diagnostic-upload route.