VS Code on Snap: The Trash Bug That's Quietly Eating Your Disk Space

TL;DR: If you installed VS Code via sudo snap install code, every file you've deleted in the editor since is probably still sitting on your disk. Snap's sandboxing redirects VS Code's trash to a hidden folder under ~/snap/code/<revision>/.local/share/Trash instead of your system trash, and nothing ever empties it. Check du -sh ~/snap/code/*/.local/share/Trash, you'll likely find gigabytes you didn't know you'd lost.

The problem

You delete a file in VS Code's explorer, empty your system trash from the file manager, and your disk usage doesn't move. That's not a fluke — it's a known bug in the Snap build of VS Code on Linux.

A user on GitHub found 20GB consumed by a single hidden trash folder. Others reported 35GB. How-To Geek documented cases topping 200GB. None of that shows up in Nautilus's trash icon, and emptying it does nothing — because the files were never sent there in the first place.

Where the files actually go

Delete something inside VS Code, and instead of landing in the standard ~/.local/share/Trash that every Linux desktop environment knows how to empty, it goes to:

~/snap/code/current/.local/share/Trash

current is a symlink to whichever revision number Snap currently has active — ~/snap/code/179/, for example. Snap keeps old revisions around after every update (the default is three), and each one has its own .local/share/Trash. Update VS Code a few times and you've got several copies of this folder, none of them connected to the one your file manager can see or empty.

Why it happens

This traces back to a VS Code change from October 2024 that sets XDG_DATA_HOME to a path inside Snap's confined per-app data directory ($SNAP_USER_DATA/.local/share) rather than the real one. Every Linux trash implementation follows the XDG trash spec, which reads XDG_DATA_HOME to decide where "deleted" files should go. Point that variable inside Snap's sandbox, and that's where the trash goes too — sealed off from the desktop's actual trash can.

Snap's confinement model makes this worse than a one-line bug. Because each revision is sandboxed separately, the trash folder isn't shared across updates, isn't cleaned up when you upgrade, and isn't touched when you "empty trash" anywhere else on the system. The bug was first reported in November 2024, a fix shipped briefly in v1.97.2, and by early 2026 it had resurfaced and was still affecting current Snap builds of both VS Code and VSCodium.

How much space you're losing right now

Run this to see every trash folder across all installed revisions:

du -sh ~/snap/code/*/.local/share/Trash 2>/dev/null

If you use VSCodium instead, swap code for codium in the path.

Cleaning it up

To clear what's already piled up:

rm -rf ~/snap/code/*/.local/share/Trash/files/* ~/snap/code/*/.local/share/Trash/info/*

This only touches the trash contents, not your actual VS Code settings or extensions, so it's safe to run.

For a longer-term fix, pick one:

• Cap how many old revisions Snap keeps, so old trash folders stop accumulating: sudo snap set system refresh.retain=2
• Drop the Snap build entirely. Install VS Code from the official .deb or .rpm package instead. Neither is sandboxed, so deleted files go straight to the real system trash like every other app. Removing the Snap package (sudo snap remove code) also wipes every leftover trash folder for free.
• If you're staying on Snap, schedule a weekly cron job that runs the rm -rf command above, so it never grows unbounded between checks.

Key takeaways

• VS Code's Snap build sends deleted files to a sandboxed trash folder, not your system trash — emptying the system trash does nothing for this.
• The hidden path is ~/snap/code/<revision>/.local/share/Trash, multiplied by however many old revisions Snap has kept.
• Real users have reported recovering anywhere from 20GB to 200GB+ once they found and cleared it.
• The root cause is a misdirected XDG_DATA_HOME variable inside Snap's confinement, tracked in vscode#233649; as of early 2026 it's still unresolved.
• The reliable fix is switching off the Snap package to .deb, .rpm, or Flatpak. If you need to stay on Snap, check du -sh ~/snap/code/*/.local/share/Trash now and clean it periodically.