Chrome was quietly using 20 GB of my Mac's disk
The problem#
I was looking at disk usage on my Mac mini and found a folder I'd never seen before, taking up 20.1 GB:#
/private/var/folders/v4/pzblyf9j6rsbjb4ngnjc6nrm0000gn/X/com.google.Chrome.code_sign_clone
It held nine folders of about 2.2 GB each. Every one contained a single item, Google Chrome.app.bundle, also 2.2 GB. So I had nine complete copies of Chrome sitting in a temp directory.#
I looked into it.#
The v4/pzblyf… part of the path is random and will be different on your Mac. The X/com.google.Chrome.code_sign_clone part is the bit to look for.#
What it is#
It's a safety mechanism Chrome has used on macOS since roughly Chrome 125 (2024).#
Chrome updates itself in the background while it's still running. macOS checks a running app's code signature against the files on disk. If an update swaps those files mid-session, the running browser can fail those checks, and helper processes, keychain access and similar things start breaking.#
To avoid that, Chrome makes a snapshot of its own app bundle every time it launches and runs from it. That gives the running copy a stable version to be checked against, whatever the updater does to /Applications/Google Chrome.app.#
Why there were nine of them#
Chrome is supposed to delete its clone when it quits. If Chrome crashes, gets force-quit, or is killed during a restart or shutdown, the clone gets left behind. Nine folders meant nine sessions that didn't end cleanly.#
Other people have hit this too, including one report of a 30 GB folder. It's worst for automation and testing tools that launch Chrome over and over, and some of those tools now switch the feature off.#
It might not really be 20 GB#
The clones are made with APFS clonefile, which shares disk blocks with the original. A clone of the Chrome version you're running now takes almost no real space, even though Finder and du report the full 2.2 GB. So it's technically not using 20 GB. But it's still using over 2 GB – an not ideal!#
Clones of older versions that have since been updated away do hold onto real space. So deleting them frees a real amount, but possibly less than the headline number. To see the actual figure, compare df -h / before and after.#
The fix#
-
Quit Chrome properly with ⌘Q. Closing the window isn't enough.#
-
Check that nothing is still running:
pgrep -l "Google Chrome"This should print nothing.#
-
Delete the folder. It belongs to your user, so you don't need
sudo:rm -rf /private/var/folders/*/*/X/com.google.Chrome.code_sign_clone ```<!--#mcvn-->
The wildcards mean you don't need to look up the random part of the path.#
Don't do this while Chrome is open. The current session's clone is in use, and deleting it can break the running browser. Chrome creates a fresh folder the next time it starts. That's expected, and one folder while Chrome is running is normal.#
Stopping it piling up again#
I've set up a Hazel rule so I don't have to remember to do this.#
- Watched folder: the
com.google.Chrome.code_sign_clonefolder. To reach it in the folder picker, press ⌘⇧G and paste the path.# - Conditions:
- Kind is Folder
- Passes shell script (embedded script):
! pgrep -x "Google Chrome" >/dev/null ```<!--#4z14-->
- Action: Move to Trash#
The shell-script condition means Hazel only clears clones when Chrome isn't running, so it never touches one that's in use.#
You can also launch Chrome with --disable-features=MacAppCodeSignClone to switch the mechanism off. I wouldn't for everyday browsing, because it brings back the mid-update breakage the feature exists to prevent.#
Quick reference for next time#
# How big is it?
du -sh /private/var/folders/*/*/X/com.google.Chrome.code_sign_clone
# Quit Chrome (⌘Q), make sure it's gone…
pgrep -l "Google Chrome"
# …then clear it out
rm -rf /private/var/folders/*/*/X/com.google.Chrome.code_sign_clone
The same thing can happen with other Chromium-based apps, such as Chromium itself and some Electron apps. Look for <app id>.code_sign_clone folders in the same X directory.#
