My editor's background linter filled the one drive I had left, 341GB at a time

The number I want to start with: 0.82GB free on C:. Measured 2026-09-01, on a machine whose only system drive is a single NVMe partition, after weeks of a Rust project growing in the background. Below a gigabyte, Windows starts refusing things quietly, and figuring out why took longer than fixing it once we knew.

The project has a rule, stated more than once: cargo only runs inside WSL. Not Windows-native, not the PowerShell terminal, WSL only, because that keeps build artifacts on a separate virtual disk and off the host filesystem. The rule held, as far as anyone building or testing the project was concerned. What it didn't cover was the editor.

VS Code's Rust extension runs rust-analyzer, and rust-analyzer runs its own background cargo check on every save, independent of whatever the human is doing in a terminal, using its own understanding of where the project's build directory is. On Windows, that means Windows-native cargo.exe and rustc.exe, writing to a Windows-native target\debug folder, with zero awareness that anyone had a rule about WSL. Seventeen of those processes were found running at once, mid-write, when someone finally went looking for the source of the bleed. The folder they'd built: 341GB, confirmed as regenerable cargo output by the presence of a CACHEDIR.TAG file, which is the actual marker tools use to tell "safe to delete, will rebuild itself" apart from a guess.

The rule wasn't wrong. It just didn't bind the thing that broke it. "Cargo runs in WSL" is a statement about where builds should happen, and rust-analyzer's flycheck feature is a separate writer that never read the rule, doesn't run inside anyone's shell session, and doesn't care what convention the humans agreed to. Stopping the bleed took two things: killing the seventeen live processes, and turning off the three VS Code settings that let rust-analyzer's flycheck touch a native build directory at all, so the regeneration path stayed sealed instead of just cleaned once.

That 341GB was one of three sources, not the whole story. WSL had its own pile of stale cargo target/ directories, about 630GB worth, accumulated the ordinary way, from target/ directories that individual work sessions never cleaned up after finishing. On top of that, the WSL virtual disk itself, the container file the whole Linux filesystem lives inside, doesn't shrink just because you deleted things inside it, a separate mechanical fact that's its own article. Between all three, cleanup and compaction together recovered close to 1TB, and the compaction step alone at the end took the container from 845.4GB down to 173.4GB, a 672GB drop measured directly before and after.

The habit I actually changed because of this: when you write a resource discipline down, "cargo builds happen in WSL," the next question has to be "what else can write to this same resource that I haven't named." An editor extension isn't a build step anyone remembers to audit. A scheduled task isn't either. Neither is a second person's session sharing the same checkout. A rule that names one writer and stops there is a rule that's already lost against every writer it didn't name, and this one had been losing quietly for who knows how long before the free space hit zero and made it loud.