Back to News & Insights
Web Development September 27, 2026 · 9 min read

Chrome cookies: why google.com survives 'delete on close', again

Chrome cookies bug: with 'delete site data on close' on, Chrome 152 keeps google.com's cookies and storage, the same exemption Google fixed in 2020.

Chrome cookies: why google.com survives 'delete on close', again

If you set Chrome to delete site data when you close all windows, Chrome 152 still keeps google.com's cookies, local storage and session storage. Jeff Johnson, the Mac developer behind Lapcat Software, reproduced it on two Macs on September 5, 2026, and a Hacker News user reproduced it in open-source Chromium the same day. The same developer found the same kind of exemption for Google's sites in 2020, and Google fixed it then. If you rely on Chrome cookies being cleared, for privacy or for testing, this is the setting not doing what it says.

TL;DR With "Delete data sites have saved to your device when you close all windows" on, and Chrome sign-in off, one Google search leaves google.com site data that survives a quit and relaunch. What survives: cookies, local storage and session storage. As far as Johnson can tell, www.google.com is the only site exempted. It reproduces in Chromium 152.0.7977.75 on Debian, so it sits in the shared code, not only in Google's branded build. In October 2020 Chrome 86 kept data for YouTube and Google Search under the equivalent setting. Google called it a bug and fixed it. Six years later it is back. I stamped it REVERT: a delete-everything setting that spares its owner is not a bug you get to ship twice.

Chrome's site data page, chrome://settings/content/siteData, has a default behaviour for all sites. The strictest choice is "Delete data sites have saved to your device when you close all windows". Site data here means more than cookies: local storage, session storage, IndexedDB and service workers, everything a site can leave on your disk to recognise you next time.

The promise is simple: close the last window and every site starts from zero. It is a middle ground between normal browsing and incognito: extensions, bookmarks and history stay, tracking state does not. Developers use it to get a clean browser for testing sign-in flows and consent banners without clearing things by hand.

Johnson's write-up sets up the cleanest case he can. On two Macs with Chrome 152.0.7977.83: Default search engine switched to DuckDuckGo. Site data set to delete when all windows close. Not signed into Chrome, and Chrome sign-in disallowed. chrome://settings/content/all empty, so no site starts with stored data.

Then one Google search, close the only window, reopen. The google.com site data is back, and it survives quitting and relaunching Chrome. It repeats every time. On disk, in ~/Library/Application Support/Google/Chrome/Default, the saved data is in Cookies, Local Storage and Session Storage. "As far as I can tell, www.google.com is the only site exempted by Chrome."

On Hacker News, saintyossarian reproduced it in open-source Chromium 152.0.7977.75 on Debian sid. That matters because Chromium is the base for most other browsers, including several that sell themselves on privacy. Whether each of them inherits the behaviour depends on what they change, so check yours rather than assume.

Nobody outside Google knows why it happens or which release regressed it. Johnson says so himself: "I'm personally inclined to cite Hanlon's razor here rather than engage in conspiracy theories. Nonetheless, Google has no excuse for incompetence either … Perhaps some kind of unit tests for this feature? Move slower and don't break things." The HN thread was less charitable. Both readings end in the same place: the one domain that ignores your setting belongs to the company that wrote the setting.

On October 7, 2020, the same author published "Chrome exempts Google sites from user site data settings" about Chrome 86.0.4240.75. With "Clear cookies and site data when you quit Chrome" on, Apple.com's data was wiped, but YouTube kept its database storage, local storage and service workers, and Google Search kept its local storage.

The Verge reported that Google called it a bug and fixed it. A fixed bug returning in the same feature, for the same owner, is what a regression test is for. A test that Google's own domains obey the user's deletion setting would have caught it.

You don't need to trust the blog post; you can look. Quit Chrome completely first, because it locks its databases while it runs. On macOS the default profile is the folder above; on Linux it is usually ~/.config/google-chrome/Default. Chrome's cookie store is an SQLite database with a cookies table, so you can list which hosts still have cookies after a "delete on close" session:

If the setting worked, that query returns nothing after you close all windows. Local and session storage live in LevelDB folders next to it (Local Storage/leveldb, Session Storage), which are harder to read but easy to list.

What you can do while this stands: Test in a fresh profile or a guest window when you need a truly clean state, instead of relying on the close-to-delete setting. Clear google.com by hand from the site data page if it matters to you, and check again after the next Chrome update. If you build on Chromium, add your own check to your release tests: set the policy, visit the vendor's own domains, close, and assert the store is empty. If you rely on privacy extensions in Chrome, note the next section.

The google.com exemption landed in a busy week for Chrome. On September 3, Chrome 152 shipped 12 security fixes, including CVE-2026-85046, a type confusion in V8. "Google is aware that an exploit for CVE-2026-85046 exists in the wild." The reporter's bounty was $1,000.

On August 31, Google removed all remaining Manifest V2 extensions from the Chrome Web Store, uBlock Origin included. Installed MV2 extensions on Chrome 138 or earlier stay but get no updates; Brave self-hosts AdGuard, uBlock Origin, uMatrix and NoScript. Tuta's reply ended with "Long live uBlock Origin!"

So in one week Chrome had a sandbox escape that paid $1,000 and a settings escape that paid Google. On Wednesday I stamped Google's Gemini 3.8 Flash SHIP IT. That stands; this is a different product.

The weekend's top Hacker News story, 1,278 points (HN), was a Mastodon post from August: "my copy of QBittorrent escaped its sandbox last night and downloaded a whole bunch of content owned by major corporations, and then my copy of Jellyfin broke containment and added those unfortunately-downloaded media files to its various libraries." The author is "conducting an internal investigation". It is a parody of the summer's AI-lab sandbox-escape reports, and the only one where everyone agrees who did it.

Isar Aerospace reached orbit. At 10:12 pm CEST on Saturday, Spectrum lifted off from Andøya, Norway, and reached orbit a little over seven minutes later, then deployed five cubesats (Space.com). It is the first orbital launch from Western European soil. The first flight, in March 2025, crashed in under a minute. CEO Daniel Metzler says "Europe now has sovereign access to space" (press release); the top HN comment notes French Guiana is EU territory.

Want to discuss this further?

Book a free strategy call with our team to see how these insights apply to your specific business goals.

Book a consultation