Gigabytes back.
Nothing you can’t rebuild.

When more than one claims the same tree, the owner is decided in this order: the packageManager field in package.json; else whichever manager's bookkeeping files are actually inside the installed node_modules; else the most recently written lockfile. Only that manager verifies, deletes and restores — the others are not consulted. Deno is outside that contest: the other four are alternatives to each other, while a repository holding both a deno.lock and a package-lock.json genuinely uses both tools. It takes vendor/ only when the Deno config asked for one — Go and Composer use that name for something else entirely — and the shared node_modules is still counted and deleted once.

uv and Poetry win over plain venv whenever their lockfile or pyproject.toml table is present, because a real lockfile rebuilds the environment exactly and a requirements.txt only approximates it. When uv and Poetry both describe the same project — usually a half-finished migration — the one whose lockfile is actually on disk owns the environment. A project with none of that falls back to venv, and a venv with an empty requirements.txt is refused outright — there would be nothing to reinstall from. Pipenv is claimed only when its environment is inside the repository — the .venv you get from PIPENV_VENV_IN_PROJECT. Its default is a virtualenv in a shared directory under your home, keyed by a hash of the project path, which a repository-scoped prune has no business reaching into.

Read-only, in every ecosystem above. cargo generate-lockfile and go mod tidy make it obvious why: they rewrite Cargo.lock and go.mod/go.sum, tracked files that would turn a cleanup into a diff you did not ask for. The same is true of npm install --package-lock-only and uv lock, so none of them run during a normal pass either. A lockfile that has drifted from its manifest is reported and the directory is left alone — because a pass can be started by the OS scheduler, and a background cleanup must never leave a modified tracked file behind. If you would rather it fixed the lockfile for you, devp config set allow_manifest_rewrite true opts in, and it means the same thing for every adapter with a lockfile. Cargo ships off. target/ is compiler output: the lockfile proves it comes back, but it comes back by recompiling rather than downloading, which on a real workspace is minutes rather than seconds. devp config set enable_cargo true turns it on, under the same build_idle_days gate as the build tools below.

Only what is inside the repository. Bundler defaults to a shared gem home outside it, so vendor/bundle is claimed and nothing else — and .bundle/ is deliberately left alone, because it holds the path configuration that sends the next bundle install back there. Composer declines vendor/ outright when a vendor/bundle is sitting inside it: deleting it would take gems with it under a proof that says nothing about them. Mix takes deps/ and never _build/, which is compiled output. CocoaPods and Mix also share the offline proof with the Dart adapter — none of the three ecosystems has a read-only in-sync check, and the write-side commands fix drift by re-downloading, so what is verified instead is that the lockfile is structurally complete and no older than the manifest it came from.

Providers only, never the rest of .terraform/. environment records the workspace you selected, and losing it silently returns you to default — so the next apply somebody runs without looking targets the wrong environment. terraform.tfstate in there is the backend's initialisation record, and rebuilding it needs the backend's credentials. modules/ is fetched from module sources that .terraform.lock.hcl says nothing about, so an unpinned git:: source can come back as something else. The providers are the bulk anyway — a few hundred megabytes of plugin binaries per root module, times every environment directory in the repository.

Off until you switch them on. A build directory takes far longer to get back than a dependency directory — a full recompile, not a download — so these seventeen, and Cargo above, ship disabled and invisible. devp config set enable_gradle true / enable_maven true / enable_swift true / enable_dart true / enable_mix_build true / enable_vcpkg true / enable_cmake_build true / enable_dotnet_build true / enable_godot true / enable_unity true / enable_unreal true / enable_defold true / enable_cocos true / enable_zig true / enable_stack true / enable_cabal true / enable_sbt true turns them on, and their candidates wait for build_idle_days (45 by default), applied as the maximum of it and idle_days — the build-tool gate can only ever make pruning later, never earlier. One adapter can be made to wait longer than the rest with devp config set adapter_idle_days cargo=90, which raises that adapter's window and never lowers it. The dependencies themselves never lived in the repository: ~/.m2, ~/.gradle and ~/.pub-cache are machine-wide stores, which is devp caches territory. Dart is here for the same reason as the others and not an obvious one: .dart_tool/ holds a second's worth of pub metadata and, beside it, the build_runner and flutter_build caches, which come back only by recompiling. vcpkg is here because it builds every port from source: what sits in vcpkg_installed/ is a compiled Boost or Qt, and vcpkg install compiles it again. It reads vcpkg.json for a dependencies list before touching anything, because every vcpkg port carries a vcpkg.json too and a port manifest rebuilds nothing. Only manifest mode is claimed — classic mode's one install tree is shared by every project on the machine, so it belongs to devp caches. CMake is the one that has to prove whose build/ it is, and the answer is never the name. cmake writes a CMakeCache.txt at the top of every tree it configures and nobody writes one by hand; that file records CMAKE_HOME_DIRECTORY, the source directory it was configured from. A directory is claimed only when that recorded source directory still exists, still holds a CMakeLists.txt and sits inside this repository — so a build/ you filled by hand is never touched. The search stops at the first cache it finds, so the sub-builds FetchContent leaves under build/_deps/ go with the tree that configured them, and it looks three levels down because Visual Studio configures into out/build/<preset>/.