[macOS] Idle sessions launch 4 parallel headless Chrome for Testing instances that abort in _RegisterApplication (crash dialog every few minutes)
Status Open
Reported on v2.1.284
Maintainer reply None cached
Workaround ✓ Mentioned in description ↑
Activity 0 comments · opened Oct 5, 2026
Summary
The Claude Code runtime bundled with Claude Desktop (claude-code 2.1.284, macOS) launches several headless "Google Chrome for Testing" instances in the background while sessions are idle (no tool call running). On macOS 14.6.1 these launches repeatedly abort in LaunchServices (TransformProcessType → _RegisterApplication → abort()), and macOS shows the "Google Chrome for Testing quit unexpectedly" crash dialog to the user every few minutes.
Environment
- Claude Desktop, Code tab; claude-code runtime
2.1.284(~/Library/Application Support/Claude/claude-code/2.1.284/claude.app/Contents/MacOS/claude) - macOS 14.6.1 (23G93), Apple M3 Pro, 18 GB
- Chrome for Testing 147.0.7727.57 from
~/.cache/puppeteer/chrome/mac_arm-147.0.7727.57(the project haspuppeteer ^24.42.0installed) - Machine uptime 12 days, load average ~20, several Claude sessions open in parallel
What happens
- 19 crash reports today (2026-10-05) between 09:20 and 09:48, all with
Responsible: claude [<pid>]where the pid is a Claude Code session process. - Crashes come in bursts: 4 Chrome main processes launched within the same second from one short-lived parent (reported as
Exited processornode), each crashing ~100 ms after launch. - The session transcripts of the responsible pids contain no tool calls at those timestamps (the sessions were idle between turns), so the launches do not come from a Bash/Browser/Artifact tool call.
- The
claudebinary contains its own headless launcher (found viastrings):--headless=new --remote-debugging-pipe --host-resolver-rules=MAP * ^NOTFOUND, EXCLUDE <host> --no-proxy-server --no-first-run --use-mock-keychain --disable-gpu --block-new-web-contents …. This looks like the preview/artifact checker. - Side effects: 31 orphaned Chrome for Testing processes (parent
launchd, oldest from 2026-09-24) and 82 leftoverpuppeteer_dev_chrome_profile-*directories in$TMPDIRaccumulated over time. Some launches succeed (profiles fully populated), others abort.
Crash excerpt
Process: Google Chrome for Testing [10521]
Identifier: com.google.chrome.for.testing
Version: 147.0.7727.57 (7727.57)
Parent Process: Exited process [10500]
Responsible: claude [89479]
coalitionName: com.anthropic.claudefordesktop
Exception Type: EXC_CRASH (SIGABRT)
Application Specific Information: abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib __pthread_kill + 8
1 libsystem_pthread.dylib pthread_kill + 288
2 libsystem_c.dylib abort + 180
3 HIServices _RegisterApplication + 12224
4 HIServices TransformProcessType + 128
5 Google Chrome for Testing Framework ChromeMain + 102030536
6 Google Chrome for Testing Framework ChromeMain + 102029752
7 Google Chrome for Testing Framework ChromeMain + 912
8 Google Chrome for Testing main + 196
Launch timestamps of the crashed processes (same parent pid per burst):
09:20:25 pids 93136 93138 93139 93141 parent 93124
09:27:16 pids 98857 98858 98859 98862 parent 98827 (+ 98866 parent 98828 "node")
09:33:37 pids 2717 2718 2719 2723 parent 2699 (+ 2724 parent 2700 "node")
09:43:32 pids 8185 8187 parent 8170
09:47:30 pids 10514 10521 10522 parent 10500
Expected
- No headless Chrome launches while a session is idle, or at least not 4 in parallel.
- A failed launch should not surface the macOS crash dialog (e.g. launch Chrome with
--no-startup-window/as a background process, or serialize launches so LaunchServices registration does not race). - Launched Chrome processes and their temp profiles should be cleaned up when the launching process exits.
Workarounds applied locally
defaults write com.apple.CrashReporter DialogType none(hides the dialog, does not fix the crash)- killed the orphaned Chrome processes and deleted the temp profiles