[BUG] Claude in Chrome: Chrome browser process self-terminates (EXC_BREAKPOINT on Chrome_IOThread / CrBrowserMain) during automation — macOS arm64, Chrome 151

Preflight

• Searched existing issues. Related but distinct: #34513 / #25518 / #30173 / #21890 / #27530 all describe a clean Chrome exit (code 0, no crash dump) or renderer/child-frame crashes. This report is the opposite case: the browser process deliberately kills itself and Crashpad does produce dumps. All of the above are closed/stale, so filing new as the bot instructs.
• Single bug report. Latest Claude Code.

Environment

• macOS 14.5 (Darwin 23.5.0), Apple Silicon (arm64)
• Google Chrome 151.0.7922.108 (latest Stable as of 2026-08-06); also reproduced on 150
• Claude in Chrome extension 1.0.85 (also on 1.0.84)
• Driven from Claude Code / Claude Desktop, several concurrent sessions
• ~10 Chrome profiles, extension deployed into several of them

What's wrong

The Chrome browser process (ptype=browser) terminates itself with
EXC_BREAKPOINT / SIGTRAP. Disassembling the faulting address gives d4200000 = BRK #0,
i.e. Chrome's own ImmediateCrash(). Every window across every profile dies at once.

8 occurrences since 2026-08-07 (4 in the last 48h). Zero before that date. No renderer crashes at all.

Forensics

Sources cross-checked 1:1 — ~/Library/Logs/DiagnosticReports/Google Chrome-*.ips and
~/Library/Application Support/Google/Chrome/Crashpad/completed/*.dmp (8 and 8).

| | |
|---|---|
| faulting thread | Chrome_IOThread ×5, CrBrowserMain ×3 |
| exception | EXC_BREAKPOINT / SIGTRAP, termination.byProc = exc handler (self-inflicted) |
| LOG_FATAL / abort message | absent — message-less NOTREACHED()-style |
| scoped key ext_event_name | set to tabs.onUpdated in 3 of 8 dumps |
| scoped key extension-function-caller-1 | set in 1 of 8 dumps |
| lower frames (IOThread cases) | identical across crashes (…0xcd3674 0x38d38e4 0x45fd68 0x1e0b024 0x1e0a914 0x37fdb88 0x1fffca0, mojo IPC dispatch); only the upper call site differs |

Why the Claude extension is the prime suspect

1. **In all 8 crashes the foreground tab (url-chunk) was a page the extension had opened or

operated on. Not one crash happened on a machine-idle/manual-browsing-only stretch.
Correction / important nuance:** checking my own tool-call logs against the 4 most recent
crashes shows the extension was not actively issuing commands at crash time —
only 1 of 4 had any browser tool call within 3 minutes (a navigate + javascript_tool
165 s earlier, no screenshot), and 2 of 4 had no browser tool call at all in the preceding
30 minutes. The last screenshot/computer burst preceded the nearest crash by ~10 minutes.
So this looks like a delayed failure — consistent with a CDP debugger session left attached
to a tab after automation finished, which then trips something later (a tabs.onUpdated storm,
an AppleScript tab enumeration, a tab close) rather than an in-the-moment crash.

1. Extension elimination. The extension-N annotations list only the extensions loaded

for the profiles open at crash time, so the set differs per crash. One crash occurred with
only 4 extensions loaded — 1Password, Claude, Google Docs Offline, Chrome Web Store
Payments — which exonerates every other installed extension. Intersecting all 8 dumps leaves
exactly two non-Google extensions: Claude and 1Password. 1Password is loaded during manual
browsing too, which never crashes.

1. The extension holds debugger + <all_urls> and drives tabs over CDP — the same surface

implicated in #34513 (debugger detach + GetAIPageContent flooding, DevTools.CDPCommandFromExtension).

Ruled out

Memory pressure (64 GB, 85–90 % free, zero swap) · FD exhaustion (11 k / 491 k) ·
system load (one crash at load 1.0, after another at load 38 → 13) · external termination ·
a specific page (different URL each time) · Chrome version (both 150 and 151) ·
all non-Claude third-party extensions (see elimination above).

Ask

Is there a known browser-side CHECK/NOTREACHED that concurrent chrome.debugger
attach/detach or rapid navigation from the extension can trip on macOS arm64 —
specifically reachable from Chrome_IOThread? If a mitigation exists (e.g. serialising
CDP attach/detach, backing off on tabs.onUpdated storms), that would be actionable today.

Minidumps can be supplied privately — they contain url-chunk values pointing at business
systems, so they are not attached here.