Chrome DevTools Protocol Browser.newContext with userDataDir: Persistence Across Unclean Shutdowns?

Chrome does not guarantee that the userDataDir remains unchanged after an unclean process termination. When Chrome is killed unexpectedly (e.g., via kill -9 or a crash), it detects the improper shutdown on the next launch and triggers recovery logic that may prune, reset, or modify specific profile files to keep the browser stable.

The reality of persistence

While Browser.newContext creates an isolated session, the userDataDir passed at browser launch is the shared persistent store underneath it. If the process dies uncleanly, the SingletonLock file is left behind. On the next start, Chrome sees that lock, infers a crash, and runs its cleanup and recovery routines before serving pages.

What gets pruned or modified

Following a crash, Chrome commonly targets these areas (exact behavior varies by version and crash type):

• GPUCache: often cleared or rebuilt when GPU shader state looks inconsistent.
• Cache and Code Cache: HTTP cache and compiled JavaScript code cache may be invalidated if their manifests appear corrupt.
• Session Storage: the most volatile layer; anything not flushed to disk before the kill is typically lost.
• Cookies / Local Storage (SQLite/LevelDB): if these databases fail integrity checks, Chrome may roll back to a prior snapshot or drop affected entries.

Signals you can actually check

There is no CDP endpoint that reports profile corruption or cleanup. Your options are filesystem-level:

• A leftover SingletonLock in the profile directory indicates the previous run did not shut down cleanly.
• Timestamps and sizes of Cache, GPUCache, and Code Cache changing on startup indicate pruning occurred.
• Launching Chrome with --enable-logging --log-level=1 (or --v=1) surfaces profile recovery messages in chrome_debug.log.

Recommended strategy for repeatable environments

1. Pass userDataDir at browser launch so all contexts share one stable profile root.
2. Before launching, remove a stale SingletonLock so Chrome does not enter recovery mode unnecessarily.
3. Hash the Cookies and Local Storage databases before and after your test run to detect unexpected modification.
4. Prefer Browser.close over killing the process so Chrome flushes in-memory state to disk.

Assumes a recent Chromium-based browser (Chrome, Edge, Brave). Pruning behavior is non-deterministic and version-dependent; verify against your pinned Chrome build.