›_ Codex Issues
Codex Issues / #40468

[macOS] Renderer CHECK failure (EXC_BREAKPOINT) when acting on a text selection inside a message; both Cmd+C and drag-start crash (26.818.61809)

Open 💬 1 comment Opened Aug 24, 2026 by pedrolucas2003-afk

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

ChatGPT/Codex Desktop 26.818.61809 (CFBundleVersion 7019), Codex Framework 151.0.7922.170

What subscription do you have?

Pro

What platform is your computer?

macOS 26.3.1 (build 25D771280a), Darwin 25.3.0, Mac15,9, Apple Silicon arm64, 16 CPUs, 48 GB RAM. Local timezone UTC-03.

What issue are you seeing?

The renderer process crashes every time I act on an existing text selection inside a rendered message. The window goes blank and reloads. Reproduction rate is 100% across every attempt I have made.

The trigger is not "copying" specifically. Two independent user actions crash it, and only one of them touches the clipboard:

  1. Select text in a message, press Cmd+C.
  2. Double-click a word in a message so it becomes selected, then press the mouse down on top of the selection (drag start). No clipboard involved at all.

Negative control: selecting text in the composer input (plain text, no rich formatting) and pressing Cmd+C does not crash. Only selections inside rendered message content crash.

The common step between the two crashing paths is serializing the current selection into a transferable payload (text/plain + text/html + RTF for the pasteboard; the same payload plus a drag image for drag start). Selection alone is harmless; consuming the selection is what dies.

Because path 2 never touches the pasteboard, third-party clipboard managers, Handoff and Universal Clipboard are all ruled out as causes.

Crash details from the local minidump

I captured a minidump before Crashpad uploaded and deleted it:

Exception:  EXC_BREAKPOINT (brk), subcode 1
Address:    0x11d3122fc
Module:     Codex Framework 151.0.7922.170
            /Applications/ChatGPT.app/Contents/Frameworks/Codex Framework.framework/
Base:       0x114c5c000  (231.9 MB image)
Offset:     0x86b62fc
Process:    renderer  (ptype "renderer" in the Crashpad sidecar, arm64)

EXC_BREAKPOINT with subcode 1 on arm64 is a brk instruction, so this is a deliberate CHECK/NOTREACHED-style abort inside the framework, not a segfault or memory corruption. Symbolizing offset 0x86b62fc against your build of Codex Framework 151.0.7922.170 should land directly on the failing assertion.

Crashpad IDs from the supervised reproduction (all {"capture_kind":"crash","ptype":"renderer","ver":"151.0.7922.170"}):

efca8733-a6f1-4a42-9bc5-c5e0dc7888b4   16:20:20
2f44015e-9076-4e79-bd22-2afdd38eea21   16:20:42
4d2a0493-e82c-442f-9214-d37b026120d8   16:21:45
4a4dd2b5-bcdf-4252-bd32-645035afc197   16:24:47  (minidump preserved locally)

What steps can reproduce the bug?

  1. Open a conversation in the ChatGPT macOS app.
  2. Select text inside a message (assistant reply).
  3. Either press Cmd+C, or double-click a word and then press the mouse down on the highlighted word.
  4. The renderer crashes. The window goes blank and reloads.

The top-level app process survives. In one observed sequence the main process stayed alive for over two hours while the renderer died repeatedly underneath it.

What is the expected behavior?

Copying or dragging selected text out of a message should not crash the renderer.

Additional information

This is a regression. The only prior renderer crash records on this machine are 2026-07-08 and 2026-07-10, so 45 consecutive days with zero renderer crashes. The app bundle updated on 2026-08-24 at 10:14 and the first crash followed 22 minutes later. 16 renderer crashes have been recorded on this machine that day alone.

Not time or leak based. Between 13:59 and 16:00 the app stayed open and idle with zero crashes. Crashes track the action, not uptime.

Also checked and ruled out: no third-party clipboard manager running; no .ips report in DiagnosticReports; nothing in the macOS unified log; no memory pressure or jetsam at the crash times; already on the newest available build.

Related but distinct: #37968 describes the same blank-window-after-renderer-crash failure mode with a different trigger.

Impact: high. Copying text out of a reply is a routine action and it currently interrupts the session every single time.

View original on GitHub ↗

1 Comment

pedrolucas2003-afk · 3 days ago

Reopening with an additional result that strengthens the report.

A third-party clipboard/translation tool (DeepL, which installs a Cmd+C+C global shortcut and a floating icon over selected text) was suggested to me as a likely cause. Ruled out by direct test.

With DeepL fully quit (no process running at all, verified by process list, not just the window closed), the renderer kept crashing on the same actions:

17:13:42  renderer crash
17:14:22  renderer crash

That brings the total to 20 renderer crashes on this machine today. So the crash does not depend on any third-party clipboard or translation tool being present. Combined with the drag-start path in the original report, which never touches the pasteboard at all, external clipboard interception is eliminated both by experiment and by mechanism.

One more negative result, in case it saves someone time: macOS ExcUserFault_LookupViewService reports (WEBKIT namespace, EXC_GUARD, responsible process ChatGPT) also exist on this machine, so LookupViewService looked like a candidate. It is not correlated. Those faults occur on 2026-08-21, 08-22 and 08-23, days with zero renderer crashes, and only 1 of today's 20 renderer crashes had a LookupViewService fault within the same second. It is background noise on this machine, not the trigger.

The original evidence stands: EXC_BREAKPOINT (brk, subcode 1) at offset 0x86b62fc in Codex Framework 151.0.7922.170, which is a deliberate CHECK-style abort inside the framework and should be symbolizable directly against your build.