Chrome Crash Bubble Blocks Automation

What Happened

Chrome sets exit_type=Crashed in the profile’s Preferences file on startup and only writes “Normal” on clean exit. Any dirty kill (SIGKILL, double Ctrl-C, OOM) leaves the profile permanently in “Crashed” state. On next launch, Chrome shows a “restore session” dialog that blocks all automation : no page navigation works until the dialog is dismissed.

Root Cause

Chrome’s crash detection is file-based, not process-based. The Preferences and Local State files persist crash markers across sessions. Automation tools that kill Chrome ungracefully (which happens frequently during development) accumulate permanent crash state. The --disable-session-crashed-bubble and --hide-crash-restore-bubble flags help but don’t prevent the underlying state corruption.

Fix

Repair both Default/Preferences AND Local State files pre-launch AND post-close. Handle whitespace variations in crash markers. Remove crash sentinel files. Comprehensive lock file cleanup. The repair function runs at both ends of the browser lifecycle to handle any dirty exits that occur during the run itself.

Lesson

Browser automation must own the profile lifecycle end-to-end. Any automation framework that starts Chrome must also guarantee clean exit state, or implement crash-state repair on startup. This applies to all Chromium-based automation (Playwright, Puppeteer, CDP).