›_ Codex Issues
Codex Issues / #38566

Repeated Codex Desktop V8 `SIGTRAP` / `brk 0` crash — 13 occurrences in ~49.5h on build 6396

Open 💬 3 comments Opened Aug 14, 2026 by xyzracehorse
💡 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.61601 (build 6396`)

What subscription do you have?

Pro

What platform is your computer?

macOS: `26.6.1 (25G76)

What issue are you seeing?

Codex Desktop is repeatedly crashing and interrupting active work. This is a follow-up to an August 12 local investigation, with seven new macOS DiagnosticReports collected on August 13–14.

Environment

  • Codex Desktop: 26.803.61601 (build 6396)
  • Bundle ID: com.openai.codex
  • Chromium base: 151.0.7922.76
  • macOS: 26.6.1 (25G76)

Frequency and impact

  • Six same-signature crashes occurred on August 12.
  • Five additional crashes occurred on August 13.
  • Two additional crashes occurred on August 14.
  • Total: 13 same-build occurrences between August 12 at 06:11:34 and August 14 at 07:43:15, about 49.5 hours.
  • The app crashed again only 2 minutes 1 second after a prior crash on August 13, and 2 minutes 24 seconds after a prior crash on August 14, indicating rapid recurrence after relaunch.
  • The crashes repeatedly interrupt active work. This needs urgent stability attention.

Repeated crash signature

All seven new reports have:

  • EXC_BREAKPOINT / SIGTRAP
  • ESR: (Breakpoint) brk 0
  • Exact Codex Framework imageOffset: 71766936
  • The same first four frames:
  1. ares_llist_replace_destructor
  2. ares_llist_replace_destructor
  3. reading_mode$cxxbridge1$194$parse_distilled_html
  4. reading_mode$cxxbridge1$194$parse_distilled_html
  • Faulting thread: CrBrowserMain in five reports and V8Worker in two reports
  • Downstream V8 garbage-collection and heap-allocation frames

The earlier investigation also found embedded OOM error in V8 and Allocation failed - JavaScript heap out of memory strings. The machine had ample physical memory at the time, supporting per-process V8 heap exhaustion rather than whole-system memory pressure.

This recurring signature is distinct from the separate August 11 EXC_BAD_ACCESS drag-and-drop renderer crash and should not be grouped with it.

Reproduction status

No single deterministic click sequence has been isolated. The failure occurs during ordinary Codex Desktop use and can recur within minutes after relaunch. Large active histories and heavy task switching appear correlated, but are not claimed as the root cause.

Expected behavior

The desktop app should remain stable during normal use and after relaunch.

Actual behavior

The Chromium/V8 process repeatedly terminates with the same breakpoint and stack signature, losing the active app session and disrupting work.

Attachments

The accompanying archive contains only these seven new macOS .ips reports:

  • ChatGPT-2026-08-13-085021.ips
  • ChatGPT-2026-08-13-091949.ips
  • ChatGPT-2026-08-13-092150.ips
  • ChatGPT-2026-08-13-104519.ips
  • ChatGPT-2026-08-13-200310.ips
  • ChatGPT-2026-08-14-074051.ips
  • ChatGPT-2026-08-14-074315.ips

Broad conversation histories, session transcripts, and unrelated application logs are not included.

Feedback-submission blocker observed on August 14

An additional Codex Desktop browser-permission defect prevented this evidence from being submitted through the official GitHub issue form:

  • github.com was added under Settings > Browser > Allowed sites.
  • No github.com entry was visible under Blocked sites.
  • Codex Desktop was fully quit and relaunched so the permission state would reload.
  • A fresh built-in browser instance still rejected https://github.com/openai/codex/issues/new/choose before the page loaded, reporting that a saved user permission setting blocks https://github.com.

Computer Use correctly refused to bypass the saved site policy. The mismatch between the visible Allowed-sites state and the enforced hidden Block state appears to be a second reproducible Codex Desktop bug. No GitHub issue URL or number was issued because the page never loaded.
[

codex-crash-evidence-2026-08-14.zip

codex-crash-evidence-2026-08-14.zip

codex-crash-evidence-2026-08-14.zip

](url)

What steps can reproduce the bug?

Reproduction status

No single deterministic click sequence has been isolated. The failure occurs during ordinary Codex Desktop use and can recur within minutes after relaunch. Large active histories and heavy task switching appear correlated, but are not claimed as the root cause.

Expected behavior

The desktop app should remain stable during normal use and after relaunch.

Actual behavior

The Chromium/V8 process repeatedly terminates with the same breakpoint and stack signature, losing the active app session and disrupting work.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 13 days ago

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

  • #38557
  • #37493

Powered by Codex Action

Rainbow0721 · 1 hour ago

Additional reproduction on newer builds (2026-08-28)

I can confirm that this crash family is still reproducible on two substantially newer ChatGPT desktop builds on Apple Silicon.

Environment:

  • macOS 15.6 (24G84)
  • MacBook Air (M4), 24 GB RAM
  • Bundle ID: com.openai.codex
  • Build 26.820.60940 (7119), Codex Framework 151.0.7922.170
  • Build 26.825.32147 (7303), Codex Framework 151.0.7922.174

Frequency:

  • 3 crashes on build 7119 at 14:51, 17:08, and 17:24 local time.
  • The app then auto-updated to build 7303.
  • 2 more crashes on build 7303 at 17:35 and 17:40.
  • On build 7303 the crashes recurred 94 seconds and 229 seconds after relaunch.

Signature:

  • EXC_BREAKPOINT / SIGTRAP
  • ESR: (Breakpoint) brk 0
  • Crashed thread: CrBrowserMain, com.apple.main-thread
  • Build 7119: exact Codex Framework imageOffset 72585164 in all three reports.
  • Build 7303: exact Codex Framework imageOffset 73131376 in both reports.
  • The same first four symbolic frames as this issue:
  1. ares_llist_replace_destructor
  2. ares_llist_replace_destructor
  3. reading_mode$cxxbridge1$194$parse_distilled_html
  4. reading_mode$cxxbridge1$194$parse_distilled_html
  • Downstream frames include V8 serialization on build 7119 and V8 GC/allocation plus Node fs callback frames on build 7303.

Correlation:

  • macOS unified logs immediately before multiple crashes show repeated RemoteHostedPIPContent active-thread changes, suppressed-thread changes, Browser Use presentation updates, and intermittent CUAService bootstrap timeouts.
  • Heavy task switching / Browser Use state restoration appears correlated, but is not claimed as proven root cause.

System-wide memory pressure was healthy, swapouts were 0, disk space was ample, and the app bundle passed strict code-signing verification and Gatekeeper notarization checks. I did not see an explicit V8 OOM message in the unified log, so this may still be an internal fatal assertion rather than confirmed heap exhaustion.

I am withholding full .ips reports publicly because they contain machine-specific identifiers. Sanitized excerpts or the reports can be provided privately if maintainers need them.

Rainbow0721 · 1 hour ago

Additional trigger condition

After further reproduction, the crashes do not appear random: they occur specifically when opening older conversations. Remaining in a new/current conversation is stable.

This narrows the likely trigger to historical-thread loading or saved-state restoration. It is not yet clear whether every older conversation is affected or only a subset (for example, long histories or conversations that previously used Browser Use / Computer Use), so that distinction should be treated as an inference rather than a confirmed root cause.

No conversation titles or contents are included here.