Chrome 152 still keeps google.com cookies despite the delete-on-close setting

Chrome 152 ignores its own delete-on-close privacy setting for one domain: google.com. Even when the browser is configured to wipe all site data when the last window closes, google.com's cookies, local storage and session storage survive a full quit and relaunch, according to a dev.to write-up summarising tests by Jeff Johnson, the Mac developer behind Lapcat Software.

What the setting is supposed to do

Chrome's site data controls, at chrome://settings/content/siteData, include a strictest option that deletes everything sites have stored on the device once all windows are closed. Site data covers more than cookies: local storage, session storage, IndexedDB and service workers all count. The promise is a middle ground between ordinary browsing and incognito, where bookmarks, history and extensions stay while tracking state does not. Developers also rely on it to start from a clean slate when testing sign-in flows and consent banners.

How the bug was reproduced

Per the dev.to write-up, Johnson constructed the cleanest possible case on two Macs running Chrome 152.0.7977.83 on September 5, 2026: the default search engine switched to DuckDuckGo, delete-on-close enabled, Chrome sign-in disabled, and no pre-existing site data listed in the site data settings. After a single Google search, closing the only window and reopening Chrome left google.com data on disk, in the Cookies, Local Storage and Session Storage stores under ~/Library/Application Support/Google/Chrome/Default. The data persisted through repeated quits and relaunches. As far as Johnson can tell, www.google.com is the only domain spared.

A Hacker News user, saint_yossarian, reproduced the behaviour the same day in open-source Chromium 152.0.7977.75 on Debian sid. That places the responsible code in the shared Chromium codebase rather than something unique to Google's branded build, which means Chromium-derived browsers could inherit it depending on how much they modify, so it is worth checking whichever one you use.

A repeat of 2020

This is not the first occurrence. On October 7, 2020, Johnson documented a near-identical exemption in Chrome 86.0.4240.75: with the equivalent clear-on-quit setting enabled, apple.com's data was wiped while YouTube kept its database storage, local storage and service workers, and Google Search kept its local storage. The story was covered by The Register, Gizmodo and The Verge, and The Verge reported that Google acknowledged it as a bug and shipped a fix. Six years later, the same class of behaviour has returned in the same feature, this time for google.com itself.

How to verify it yourself

Chrome locks its databases while running, so quit it completely first. On macOS the default profile lives in ~/Library/Application Support/Google/Chrome/Default, on Linux usually in ~/.config/google-chrome/Default, with recent versions keeping the cookie store in Default/Network/Cookies and older ones in Default/Cookies. The store is an SQLite database, so one query lists any surviving Google cookies:

sqlite3 Network/Cookies "SELECT host_key, name FROM cookies WHERE host_key LIKE '%google.com';"

If the setting worked as documented, that query returns nothing after all windows are closed. Local and session storage sit in LevelDB folders alongside the cookie store.

Workarounds for now

Until Google fixes or explains the behaviour, a fresh profile or a guest window is the reliable way to get a genuinely clean state. Clearing google.com by hand from the site data page works but needs repeating after each session. Teams shipping Chromium-based browsers can add a regression test: enable the policy, visit the vendor's own domains, close the browser, and assert the store is empty.

Why it matters

Nobody outside Google knows which release reintroduced the behaviour or why, and Johnson says as much himself. He leans toward Hanlon's razor rather than conspiracy theories, while arguing that Google has no excuse for breaking the same feature twice, and suggests unit tests as the remedy. Whatever the cause, a delete-everything setting that quietly exempts the browser vendor's own domain breaks the one guarantee the setting makes. For privacy-minded users it means silent retention of Google identifiers; for developers it means test pollution that looks like a bug in their own code. A single test asserting that google.com obeys the user's deletion setting would have caught the regression in 2020, and again now.