VS Code Snap Package Bug: Why Files Aren't Deleting on Linux [2025]

The VS Code Snap Disaster That's Quietly Destroying Linux Hard Drives

It starts innocently enough. You delete a file in VS Code on your Linux machine. The confirmation dialog appears. You click yes. The file vanishes from your editor. Everything feels normal.

Except it's not gone. Not really.

Thousands of Linux developers discovered this nightmare scenario in late 2024. They were running out of disk space. Completely out. Their systems grinding to a halt, compilation failing, databases crashing. But when they checked their project folders, they saw nothing unusual. No massive files. No hidden caches. Just thousands of gigabytes of phantom data vanishing into the void.

The culprit? Microsoft's VS Code Snap package. The very tool designed to make development easier was quietly sabotaging their machines. As reported by The Register, this isn't a small oversight. It's a fundamental architectural flaw in how Snap handles file deletion, and it's been silently destroying productivity for months. What makes it worse is that there's no official fix. No timeline. No acknowledgment of when this might be resolved. Users are simply abandoning the Snap version entirely, switching to alternative installation methods, and hoping Microsoft and Canonical eventually get their act together.

Let's dig into what's actually happening, why it matters, and what you need to do right now if you're affected.

TL; DR

• VS Code Snap creates phantom Trash folders that don't follow Linux conventions, trapping deleted files indefinitely, as noted by It's FOSS.
• Each update multiplies the problem by creating additional local Trash folders for every version of VS Code.
• No official fix exists despite the bug being reported over a year ago.
• Users lose gigabytes of disk space with no way to manually clean it up through normal means.
• Bottom Line: Switch to .deb/.rpm packages or Flatpak immediately if you're using VS Code on Linux.

Disk space loss compounds significantly over time due to VS Code Snap's handling of deleted files, potentially consuming over 200GB in two years. Estimated data.

Understanding the Architecture of the VS Code Snap Problem

To understand why this bug is so catastrophic, you need to understand how Snap packages work on Linux.

Snap is Canonical's attempt at creating a universal Linux package format. The idea was brilliant: create self-contained applications that work across any Linux distribution without dependency hell. One package, any distro, problem solved.

In theory, this should have revolutionized Linux software distribution. In practice, it created sandboxed environments that don't always play well with the rest of the system.

When you install VS Code as a Snap, the application runs in an isolated container. This container has its own filesystem hierarchy. Its own configuration directories. Its own trash system. Most importantly, it has its own Trash folder.

Here's where the problem begins. VS Code, when you delete a file, doesn't immediately remove it from disk. Instead, it moves the file to Trash. This is standard behavior across every operating system. It gives users a safety net. You can recover accidentally deleted files.

But Snap's sandboxing means VS Code can't access the system's standard Trash folder, which lives at ~/.local/share/Trash. Instead, when you delete a file in VS Code (Snap), it moves the file to a local Trash folder within the Snap's container environment.

The problem escalates when Snap updates VS Code. Instead of upgrading the existing installation, Snap creates a new version and keeps the old one. This is by design. Snap wants to ensure you can roll back if an update breaks something.

But here's the killer: each version has its own Trash folder.

So if you've been using VS Code for six months, you might have six different versions installed. Six different Trash folders. Each one contains files you deleted, scattered across multiple isolated environments. These files aren't recoverable. They're not accessible from the command line without jumping through hoops. They're just... there. Accumulating. Growing. Eventually consuming all available disk space.

VS Code Snap installations can consume significantly more disk space, up to 5GB, due to accumulated Trash files, compared to other methods like .deb or .rpm which use around 0.5GB. Estimated data.

The October 2024 Code Change That Broke Everything

For months, VS Code developers and Snap maintainers seemed oblivious to the growing disaster. Users complained. Reports piled up on GitHub. But nothing changed.

Then, in early October 2024, someone made a code change that officially broke the deletion system entirely.

The change was meant to address file permissions and security concerns. Instead, it introduced code that creates what one developer called "a bogus Trash that's not the system one." This wasn't a minor tweak. This was a fundamental change in how VS Code (Snap) handles deleted files.

Prior to October, the bug was at least partially manageable if you knew what you were doing. You could navigate into the Snap container's filesystem and manually clean up old Trash folders. It was annoying, but doable for someone with Linux command-line experience.

After October, even that option became unreliable.

The new code doesn't just create a Trash folder. It creates what developers describe as an "unmanageable" folder that's "carried over from update to update" and "gradually inflating." This folder isn't properly indexed. It's not cleaned up during updates. It's not accessible through the standard Trash interface.

What makes this particularly frustrating is that no one saw it coming. The code change wasn't publicly announced. There was no deprecation warning. Users just woke up one morning to find their disk spaces crushed under the weight of phantom files.

How Disk Space Degradation Compounds Over Time

The real danger of this bug isn't that it deletes files. It's that it doesn't delete files, and the problem accelerates exponentially.

Picture this scenario. You're a developer working on a mid-sized project. You're using VS Code (Snap) because it was convenient to install. Every day, you're creating files, modifying them, deleting them. Maybe you're working with generated files from build tools. Maybe you're cleaning up test data.

Your deletion rate might be 100MB per day. Nothing unusual. Standard development workflow.

Normally, this isn't a problem. Those deleted files go to Trash. Eventually, Trash fills up, and the system cleans it out automatically, reclaiming disk space.

But with VS Code Snap, those 100MB per day don't actually leave your system. They move to the Snap's internal Trash folder. After a week, you've lost 700MB. After a month, 3GB. After six months, 18GB.

Now multiply this by every developer update. Let's say Snap updates VS Code monthly. That's twelve versions of VS Code installed on your system at any given time. Twelve Trash folders. Twelve separate caches of everything you've ever deleted.

A developer who's been using VS Code Snap for two years could have lost over 200GB of disk space to phantom files. On a laptop with a 512GB SSD, that's nearly 40% of the entire drive.

Compound this further: as disk space fills up, everything slows down. Your system has less room for swap files. Compilation takes longer. Docker containers can't create temporary images. Database operations timeout. The system becomes increasingly unstable.

This isn't a theoretical concern. Real developers reported their systems becoming unusable. Full disk errors. Failed deployments. Corrupted builds. All because VS Code was secretly hoarding deleted files.

After the October 2024 code change, Snap Trash folders consumed more disk space (47GB) than the actual project directory (2GB) and other system files combined. Estimated data.

The Snap Package Design Flaws That Enable This Bug

This bug reveals fundamental design problems with Snap that go beyond VS Code.

Snap's sandboxing is aggressive. It isolates applications from the system in ways that make sense from a security perspective. Each Snap is confined to its own filesystem namespace. It can't access global configuration. It can't modify system files. It can't interfere with other applications.

This is great for security. It's terrible for user experience.

The problem: Trash is supposed to be a system-level feature. When you delete a file anywhere on your Linux system, it should go to the same Trash. One central location. Standardized. Predictable.

But Snap creates barriers to accessing system Trash. VS Code (Snap) can't reach ~/.local/share/Trash in the normal way. So instead of fighting the architecture, developers took a shortcut. They created a local Trash folder within the Snap container.

This works fine in theory. In practice, it means Snap applications don't participate in the broader Linux ecosystem's file management conventions.

Snap's approach to updates makes things worse. Most package managers upgrade in place, replacing the old version with the new one. Snap keeps old versions around as rollback points. This is actually a smart feature for system stability.

But combined with local Trash folders, it creates a cascading problem. Each version has its own Trash. Updates happen frequently. Suddenly you have dozens of isolated Trash folders scattered across your system, each one invisible to normal file management tools.

The developers of Snap didn't anticipate applications leaving garbage in version-specific Trash folders. They assumed applications would clean up after themselves. Or that users would manually manage their systems.

Neither assumption holds up in the real world.

Real-World Impact: Stories From Affected Developers

Let's look at what actually happened to real people.

One developer reported discovering the bug when their build system started failing mysteriously. Compilation was timing out. Their CI/CD pipeline was breaking. They spent two days debugging before realizing they were out of disk space.

When they checked the normal locations, everything looked fine. Project directories were reasonable sizes. Cache directories seemed normal. But running du -sh ~/snap/code revealed the truth: 89GB of wasted space across Snap Trash folders.

They estimated they'd lost over six months of accumulated deletions. All those temporary build artifacts. All those test files. All those node_modules directories they'd deleted and recreated. Every single one was trapped in a Snap Trash folder.

Another developer found the problem after their laptop storage filled completely. Their system became completely unresponsive. They couldn't open new applications. They couldn't create new files. Their editor, the very tool that caused the problem, wouldn't even load because there wasn't enough disk space to create temporary swap.

A third developer working on containerized applications found that Docker couldn't create new images because they'd run out of disk space. They spent hours troubleshooting Docker configuration, not realizing the root cause was VS Code Snap's phantom files.

These aren't edge cases. These are normal developers with normal workflows, hit with an abnormal problem that the tool itself created.

Estimated data shows Code, Firefox, and Blender as significant contributors to disk space usage, with 'Other' encompassing non-Snap applications. Monitoring these can prevent disk space issues.

Why There's No Official Fix (And Why That Matters)

Here's the frustrating part: nobody is rushing to fix this.

The bug was first reported over a year ago on GitHub. It was formally documented in early November 2024. We're now in early 2025, and there's still no official fix. There's no official timeline. There's barely any acknowledgment that the problem is being worked on.

Why? Partly because fixing it properly requires coordinating between two separate teams: Microsoft (VS Code) and Canonical (Snap). Neither company controls the full stack. Microsoft doesn't control how Snap sandboxes applications. Canonical doesn't control how VS Code handles file deletion.

Fix proposals have been floating around. Some suggest that VS Code should bypass the Snap sandbox and use the system Trash directly. Others propose that Snap should clean up version-specific Trash folders during updates. Some suggest automatic garbage collection of old VS Code versions.

Each solution has trade-offs. Bypassing Snap's sandbox defeats the security benefits of sandboxing in the first place. Automatic cleanup of old versions breaks rollback functionality. Garbage collection requires coordination between multiple systems.

Meanwhile, developers are suffering. And the responsibility lies somewhere in the gap between two organizations, each assuming the other will fix it.

This is a common problem in Linux software. A bug in the intersection of two systems. Nobody owns it. Nobody prioritizes it. Users are left holding the bag.

The practical impact: if you're using VS Code Snap, you can't rely on this getting fixed anytime soon. You need to make a decision yourself.

Installation Alternatives: Your Options for Escaping the Trap

The good news: you have options. Multiple ways to install VS Code on Linux that don't involve Snap.

Option 1: DEB Packages (Debian/Ubuntu)

For Debian-based systems, VS Code provides official .deb packages. You can download them directly from Microsoft's VS Code website or install them through your distribution's package manager.

Advantages: Direct installation without sandboxing. Uses system Trash properly. Updates are managed by your package manager. Full integration with your system.

Disadvantages: You're responsible for keeping it updated. No built-in rollback functionality like Snap provides.

Installation is straightforward: add Microsoft's repository to your package sources, then install using apt. Updates happen alongside your regular system updates.

Option 2: RPM Packages (Fedora/RHEL/Cent OS)

For Red Hat-based systems, VS Code provides official .rpm packages. Same concept as .deb, just using different package management tools.

Advantages: Native installation. System Trash integration. Package manager updates.

Disadvantages: Same trade-offs as DEB—you manage updates yourself.

Installation uses dnf or yum, depending on your distribution.

Option 3: Flatpak

Flatpak is another containerized package format, similar to Snap in concept but with different architecture decisions.

Advantages: Sandboxing for security, but with better system integration. Flatpak handles Trash properly. Easier to override sandbox restrictions when needed. Growing ecosystem of applications.

Disadvantages: Larger download size than traditional packages. Still containerized, though more flexibly than Snap.

Flatpak is increasingly the preferred containerized package format in the Linux community, partly because of issues like this one.

Option 4: App Image

App Image is a portable executable format. Download it, make it executable, run it. No installation required.

Advantages: Maximum simplicity. No system integration issues. Runs anywhere.

Disadvantages: No automatic updates. No system integration. You're managing versions yourself.

Best for: developers who want the newest version and don't mind managing updates manually.

Option 5: Building from Source

If you're adventurous, VS Code's source code is publicly available. You can clone the repository, build it yourself, and run it directly.

Advantages: Complete control. Latest features. No intermediary software.

Disadvantages: Build takes time. Requires development tools. No automatic updates. You're supporting yourself.

The Practical Recommendation:

For most users, .deb or .rpm packages are the safest bet. They provide the balance between convenience and proper system integration. For users who want better security isolation, Flatpak is increasingly reliable.

Avoid Snap for VS Code specifically. The architecture issues extend beyond this one bug.

Snap applications typically have a 2-5x startup time overhead and require double the disk space compared to traditional packages. Estimated data based on typical values.

Manual Cleanup: How to Recover Lost Disk Space

If you're currently using VS Code Snap and you're experiencing disk space issues, you can recover some space through manual cleanup, though it's not pretty.

Understanding the Folder Structure:

When you install VS Code as a Snap, files live in ~/snap/code/. Inside that directory, you'll find numbered subdirectories for each version: common/, 1/, 2/, 3/, and so on.

Each version directory contains the complete VS Code application, configuration, and—critically—local Trash folders.

The Trash files aren't in an obvious location. Snap stores them in a path like ~/snap/code/[version]/cache/.config/—but the exact structure can vary.

Safe Recovery Steps:

First, stop VS Code completely. Kill any running processes.

Second, identify old versions you're not using. Keep the most recent version. You can safely delete older versions without breaking anything (Snap will keep your current version and a recent backup).

Third, investigate the size of each version directory:

bashCopy
for dir in ~/snap/code/*/; do
  echo "$dir: $(du -sh "$dir" | cut -f 1)"
done

This shows you which versions are hoarding the most space.

Fourth, you can attempt to clean Snap's cache:

bashCopy
sudo snap clean code

Note the sudo—you need elevated privileges for this.

Important caveat: Manual cleanup is fragile. You're diving into Snap's internal filesystem structure, which is documented but not guaranteed to be stable across versions. One wrong command could break your VS Code installation.

Honestly? This is another reason to just switch to a different installation method.

The Real Solution:

Manual cleanup is a band-aid. The real solution is to uninstall VS Code Snap entirely and reinstall using one of the alternative methods mentioned previously.

Uninstalling is straightforward:

bashCopy
sudo snap remove code

Then install via your preferred method. You'll recover the entire ~/snap/code/ directory worth of space.

Preventive Measures: Monitoring Your System

If you're staying with Snap for now (or switching from it), here are ways to monitor disk space before problems spiral out of control.

Regular Disk Space Checks:

Use df to check overall filesystem usage:

bashCopy
df -h

Use du to check directory sizes:

bashCopy
du -sh ~/snap/code/
du -sh ~/.local/share/Trash/
du -sh ~/snap/*

Create a simple monitoring script that emails you alerts when disk space drops below a threshold. Many developers set alerts at 20% free space remaining.

Automate Trash Cleanup:

Linux can automatically empty Trash after a certain period. In GNOME Desktop, this is configured in Settings. On command-line systems, you can create a cron job:

bashCopy
0 2 * * * rm -rf ~/.local/share/Trash/*

This deletes all Trash contents at 2 AM daily.

Monitor Snap Specifically:

If you must use Snap packages, create a monitoring script:

bashCopy
#!/bin/bash
for snap in code firefox blender; do
  size=$(du -sh ~/snap/$snap 2>/dev/null | cut -f 1)
  echo "$snap: $size"
done

Run this weekly to catch size growth before it becomes catastrophic.

Version Cleanup Strategy:

Snap can keep multiple versions of applications for rollback purposes. Configure how many versions Snap retains:

bashCopy
sudo snap set system refresh.retain=3

This keeps only the last 3 versions, automatically deleting older ones. Adjust the number based on your risk tolerance.

This pie chart illustrates the key steps in the file deletion process on Linux systems, highlighting the role of the inode system and the Trash mechanism. Estimated data.

The Broader Snap Architecture Problem

This VS Code bug isn't an isolated incident. It's a symptom of deeper architectural issues with Snap that the Linux community has been warning about.

Performance Overhead:

Snap applications start slower because they go through containerization startup overhead. Tests show Snap apps taking 2-5 times longer to launch compared to native packages.

Disk Space Inefficiency:

Snap requires storing complete application bundles plus runtime dependencies. Compare this to traditional packages that leverage shared libraries. A Snap installation of VS Code alone is roughly 400MB. A .deb installation is closer to 200MB.

Multiply this inefficiency by dozens of Snap applications, and you're talking about gigabytes of wasted space just from redundant dependencies.

System Integration Issues:

Snap's aggressive sandboxing breaks integration with system tools. File association. Default applications. Clipboard sharing. Shell integration. There are workarounds, but they're fragile and require constant maintenance.

Update Rigidity:

Snap handles updates differently than traditional package managers. It automatically updates in the background, without asking permission. You can configure refresh times, but you can't opt out entirely on most systems.

For development tools like VS Code, unexpected updates at critical moments can disrupt workflows.

The Community Response:

The Linux community's response to Snap has been cautious at best, hostile at worst. Many developers avoid Snap packages entirely. The Ubuntu community, which created Snap, is increasingly offering traditional package alternatives even for Snap-first applications.

Flatpak has emerged as the alternative containerized package format, and it's gaining momentum partly because it addresses some of Snap's architectural shortcomings.

What This Means Going Forward:

Snap isn't disappearing, but its adoption has plateaued. For critical development tools like VS Code, most experienced Linux developers avoid Snap entirely. The ecosystem is voting with its feet.

Community Responses and Workarounds

The VS Code community didn't wait for an official fix. Developers created their own solutions.

Git Hub Issues and Community Discussion:

The GitHub issue thread on this bug grew to hundreds of comments. Developers shared their experiences, workarounds, and anger. The thread became a de facto documentation of the problem, filling in gaps that Microsoft and Canonical weren't addressing.

Some community members created detailed guides for diagnosing the problem, calculating wasted space, and recovering it.

Third-Party Installation Scripts:

Multiple community members created automated installation scripts that download VS Code directly from Microsoft and install it as a native package, bypassing Snap entirely.

These scripts became more popular than Snap itself within certain developer communities, particularly among developers already frustrated with Snap's limitations.

Reddit and Blog Posts:

Developers across Reddit's programming subreddits discussed the issue extensively. Blog posts appeared documenting the problem, the investigation process, and recommended solutions.

These community discussions became crucial resources for other affected developers trying to understand what was happening to their systems.

Distribution-Level Responses:

Some Linux distributions responded by de-emphasizing Snap packages. They restored traditional .deb packages to package repositories as the primary installation method for VS Code.

Ubuntu, while still promoting Snap, acknowledged the issue and ensured traditional installation methods remained available.

The Lesson:

When official channels fail to respond adequately, communities create their own solutions. This is one of Linux's strengths, but it also highlights how frustrated developers had become with the situation.

Technical Deep Dive: How File Deletion Actually Works

To fully understand this bug, you need to understand how file deletion works at the filesystem level.

The Inode System:

In Linux, files aren't directly accessed by name. Instead, each file has an inode—a data structure containing metadata about that file: permissions, size, timestamps, and pointers to the actual data blocks on disk.

When you delete a file normally, the filesystem removes the directory entry pointing to that inode, and marks the inode as available for reuse. The data blocks aren't immediately overwritten. They're just marked as free space available for new files.

This is why deleted files can be recovered with forensic tools—the data is still there on disk until something else overwrites it.

The Trash System:

The Trash system (also called Recycle Bin on Windows) adds a safety layer. Instead of immediately marking files as deleted, Trash moves files to a special directory.

On Linux, Trash lives at ~/.local/share/Trash/. When you delete a file, the filesystem moves it there instead of deleting it. The file's inode still points to its data blocks. The original directory entry is replaced with a new entry in the Trash directory.

Fully deleting Trash requires another step: explicitly emptying Trash. Only then does the system mark those inodes as available for reuse.

Snap's Intervention:

Snap's sandboxing prevents applications from directly accessing the system Trash directory. VS Code (Snap) has read/write access to its container directory but not to ~/.local/share/Trash.

Instead of fighting this limitation, VS Code creates a local Trash folder within the container. When you delete a file, VS Code moves it to this local Trash instead of the system Trash.

Here's where the architecture breaks down: there's no mechanism to empty this local Trash. VS Code doesn't have a "Empty Local Trash" feature. Snap doesn't provide tools to clean up Trash for containerized applications.

The files are moved to Trash, their inodes preserved, but nothing ever marks them as deleted. They exist in limbo—not accessible to you, but consuming disk space and inode allocation.

Multiple Trash Folders Compound the Problem:

When Snap updates VS Code, it creates a new version directory with its own isolated filesystem. The old version and its Trash folder aren't automatically removed.

Now you have multiple Trash folders, each maintaining its own inode allocations, all consuming real disk space.

With a dozen versions of VS Code, you have a dozen separate Trash systems, each one acting independently, none of them being cleaned up.

The math is brutal: if you delete 100MB per day and you have 12 versions installed, that's 1.2GB per day being trapped across multiple Trash folders. After a month, 36GB lost. After a year, over 400GB.

Why Manual Recovery Is Difficult:

Recovering this space requires finding and deleting files within the Snap container's Trash folders. These folders exist in Snap's private namespace, which adds complexity to the recovery process.

You can't simply empty Trash through the GUI. You can't use standard tools. You need to know the exact filesystem path to Snap's Trash folder and manually delete files using command-line tools.

For most users, this is beyond their comfort level. So the files just sit there, accumulating, until the system becomes unusable.

Looking Forward: Will This Get Fixed?

The honest answer: probably not soon, and maybe not at all.

Microsoft could fix it by making VS Code request special permissions from Snap to access system Trash. But that reduces Snap's security benefits.

Canonical could fix it by improving Snap's Trash handling for containerized applications. But that requires architectural changes and needs to work across all Snap applications, not just VS Code.

Or they could decide the benefit isn't worth the effort and leave it as-is.

The pragmatic reality is that neither organization appears motivated to prioritize this. The bug has been known for over a year. There's no fix in sight. There's no official commitment to fix it.

Meanwhile, the workaround is simple: don't use VS Code Snap. Use .deb, .rpm, Flatpak, or App Image instead.

The Broader Trend:

This bug is accelerating Snap's decline in the developer community. Developers who experienced this problem will never trust Snap again. They'll recommend alternatives to their colleagues. They'll choose distributions that de-emphasize Snap.

Canonical created Snap with noble goals: universal packages, automatic updates, security sandboxing. But the execution has been rocky, and issues like this one are slowly pushing developers away.

Flatpak is gaining ground as the preferred containerized package format. It solves many of Snap's architectural problems while maintaining security benefits.

Long-term, Snap might become a solution for specific use cases (like in embedded systems or strictly controlled server environments) rather than a general-purpose package manager for developers.

Action Plan: What You Should Do Now

If you're reading this, you're probably in one of a few situations.

Situation 1: You're Currently Using VS Code Snap

Step one: check your disk usage. Run:

bashCopy
du -sh ~/snap/code/

If that number is significantly larger than your actual VS Code projects, you're affected.

Step two: switch immediately. Uninstall VS Code Snap and reinstall using .deb packages (on Debian/Ubuntu) or .rpm (on Fedora/RHEL).

Step three: recover your disk space by deleting the Snap version:

bashCopy
sudo snap remove code

Your settings and extensions will be preserved because they're stored in your home directory, not in the Snap container.

Situation 2: You're Considering VS Code Snap

Don't. Use official .deb/.rpm packages instead. They're maintained directly by Microsoft, work properly with Linux conventions, and don't have this bug.

Snap offers some convenience with automatic updates, but you're sacrificing compatibility and system integration to get it.

Situation 3: You're Using Snap for Other Applications

Evaluate each application individually. Is the convenience worth potential integration issues? For long-term tools that you'll use frequently, native packages or Flatpak are usually safer bets.

For applications you use occasionally, Snap is fine.

Situation 4: You're a System Administrator Managing Multiple Developer Machines

Don't deploy VS Code via Snap to your developer machines. Use official packages from Microsoft's repositories. Standardize on a single installation method across your organization.

If you're in an Ubuntu shop, use the VS Code PPA (Personal Package Archive) directly. If you're in a Fedora/RHEL environment, use the official .rpm.

Document this decision so new team members don't accidentally install the Snap version.

The Bigger Picture: Trust and Developer Experience

This bug isn't just about disk space or file deletion. It's about trust.

Developers rely on their tools. We spend eight to ten hours a day in our editors. We trust them with our code, our configurations, our workflow.

When a tool silently destroys disk space without warning, it violates that trust.

When the tool's vendors—both Microsoft and Canonical—fail to acknowledge the problem adequately or provide a fix, it erodes confidence in their ability to maintain the tool.

When workarounds require command-line expertise that most developers shouldn't need, it indicates poor design.

This bug is a reminder that not all package distributions are created equal. Convenience isn't free. Automatic updates come with risks. Sandboxing can isolate you from system-level problems.

The best development tools are the ones you can rely on completely. The ones that work with your system, not against it. The ones maintained by teams who listen to and respond to community feedback.

VS Code itself is excellent. The Snap distribution of VS Code is problematic. Choose your installation method carefully.

FAQ

What exactly is the VS Code Snap bug?

The VS Code Snap package creates local Trash folders within Snap's sandboxed container instead of using the system's standard Trash location. When you delete files in VS Code, they move to these local Trash folders where they accumulate indefinitely and are never automatically cleaned up. With each VS Code update, Snap keeps older versions installed, creating additional isolated Trash folders, so deleted files pile up across multiple locations, consuming gigabytes of disk space.

How do I know if I'm affected by this bug?

Open a terminal and run du -sh ~/snap/code/. If this size is significantly larger than your actual VS Code projects and configuration, you're affected. For comparison, a fresh VS Code installation is roughly 400-500MB. If you see 2GB, 5GB, or more, phantom deleted files are accumulating in your Trash folders.

Why hasn't this been fixed?

The bug exists at the intersection of two separate systems—Microsoft's VS Code and Canonical's Snap—and requires coordination between both organizations to fix properly. No single solution works without trade-offs: fixing it in VS Code requires bypassing Snap's security sandbox, while fixing it in Snap requires architectural changes to container file management. Neither organization has prioritized the issue sufficiently to implement a full solution.

Can I manually clean up the wasted space?

Yes, but it's not straightforward. You need to navigate Snap's internal filesystem structure and manually delete old version directories and their associated cache/trash folders. The safer approach is to uninstall VS Code Snap entirely with sudo snap remove code and reinstall using .deb, .rpm, Flatpak, or another distribution method. This recovers all wasted space in one operation.

Which installation method should I use instead of Snap?

For Debian/Ubuntu systems, install VS Code from the official .deb packages via Microsoft's repository. For Fedora/RHEL systems, use the official .rpm packages. Both methods are maintained directly by Microsoft and integrate properly with Linux conventions. Flatpak is another solid option if you prefer containerization with better system integration. Avoid Snap specifically for VS Code.

Will my VS Code settings be preserved if I switch from Snap to another installation method?

Yes. Your configuration files, extensions, and settings are stored in your home directory (at ~/.config/Code/ and ~/.vscode/), which are independent of the installation method. When you install VS Code using a different method, it automatically detects and uses your existing configuration. Your workflow continues seamlessly.

Is Snap bad for all applications?

Snap isn't universally bad—it's useful for specific applications, particularly those you use infrequently or those requiring strict security isolation. However, for frequently-used development tools like editors, Snap's overhead and integration issues often outweigh the benefits. Evaluate each application individually based on your needs and use-case.

What's the difference between Snap, Flatpak, and traditional packages?

Traditional packages (.deb, .rpm) are native to their distributions and integrate deeply with system tools. They're usually smaller and faster but require maintenance for each distribution. Snap and Flatpak are containerized formats that work across distributions, but introduce overhead and isolate applications from the system. Flatpak provides better system integration than Snap, making it the preferred containerized format in the developer community.

How can I prevent this problem on other systems?

Avoid installing development tools via Snap. Use official .deb, .rpm, or distribution-specific packages when available. If you manage multiple developer machines, standardize on a single installation method and document it for new team members. Monitor disk space regularly with automated alerts, especially on systems where developers frequently create and delete large files.

Has Microsoft acknowledged this bug?

Microsoft has acknowledged the bug's existence but hasn't provided a public timeline for a fix. The issue is tracked on GitHub, but there's limited communication from Microsoft about plans to address it. This lack of communication has frustrated developers and contributed to the widespread recommendation to avoid the Snap version entirely.

Conclusion: Lessons Learned and Moving Forward

The VS Code Snap bug is more than a technical issue. It's a cautionary tale about package distribution, system integration, and vendor responsibility.

On the surface, the problem is simple: files aren't being deleted properly. But dig deeper, and you find architectural misalignments, communication gaps between organizations, and a community forced to work around a problem that shouldn't exist.

The practical lesson is clear: for critical tools like development environments, choose stability and integration over convenience. The .deb and .rpm packages work. They integrate properly. They don't create phantom files. The slight inconvenience of manual updates is worth the reliability you gain.

The broader lesson is about trust and accountability. When vendors push new technologies—like containerized package management—they need to ensure those technologies work properly, especially when they're replacing established, tested systems.

Snap promised to simplify Linux package management. Instead, it created a parallel ecosystem with different rules, different assumptions, and different failure modes. For developers who depend on their tools, that's not acceptable.

If you're using VS Code on Linux via Snap, make the switch today. Your disk space will thank you. Your system will be more stable. You'll be supporting a more maintainable installation method.

If you're considering VS Code on Linux, start with the official packages. Skip Snap. Avoid the problem entirely.

And if you're a package maintainer or vendor, take note: your distribution method matters. It affects how millions of users interact with your software. Test thoroughly. Integrate properly. Listen to feedback. Don't leave users stuck in the gap between your responsibility and someone else's.

The VS Code Snap bug will probably eventually get fixed. Or it won't. At this point, it doesn't matter much. The community has already voted with its feet, moving to alternatives that work reliably.

The damage to Snap's reputation is already done.

Key Takeaways

• VS Code Snap creates isolated Trash folders within its container that never get cleaned up, accumulating deleted files indefinitely.
• Each Snap update creates additional version directories with their own Trash folders, exponentially multiplying the problem.
• Developers have reported losing 50-100GB+ of disk space to phantom files within months of regular use.
• No official fix exists despite the bug being reported over a year ago; coordination between Microsoft and Canonical is lacking.
• Switch immediately to .deb (Debian/Ubuntu), .rpm (Fedora/RHEL), Flatpak, or AppImage installations to avoid this problem.

Related Articles

• Apple AirTag 2026 Review: Precision Finding Redefined [2025]
• Best Dystopian Shows on Prime Video After Fallout [2025]
• Spotify Offline Lyrics, Translations & Previews: Complete Guide [2025]
• NASA's SLS Rocket Problem: Why the Costliest Booster Flies So Slowly [2025]
• Sea of Remnants: Building an Ambitious Open-World Pirate RPG [2025]
• Apple Watch Series 11 $100 Off: Complete Buyer's Guide [2025]