GeezerVison

New file crates/socket-patch-cli/tests/common/cache_env.rs. The whole interface is:

cache_env::isolate(&mut cmd);

It points that one child at a sandbox under the OS temp directory. common/mod.rs re-exports it, and the self-contained suites (this repo's convention is that e2e files carry their own helpers) pull in just this module with #[path = "common/cache_env.rs"] mod cache_env;.

The good pattern already in the repo is the one e2e_vendor_npm_build.rs and e2e_vendor_bun_build.rs use: hand the fixture install a private cache directory. Both of those measure clean today. What the helper does is generalise it, so a suite gets the whole set by default instead of having to remember one variable at a time.

A redirected HOME alone still leaves the real cache in play whenever one of these is exported — and CI actions export them too (pnpm/action-setup sets PNPM_HOME). So each is pinned explicitly:

XDG_CONFIG_HOME is deliberately left alone. It is not a cache, and when someone has set it explicitly it usually points at real configuration — a registry mirror, a corporate CA bundle — that the installs still need.

This is the part that would have bitten people. rbenv, pyenv, nvm, fnm, volta, asdf, mise, sdkman and rustup all live under the home directory by default. Move HOME without carrying them and the shim cannot find its own root, so ruby or node or cargo fails to launch at all.

That failure would have been quiet rather than loud: most of these suites respond to a failed fixture install by printing SKIP and returning, so the coverage would have vanished without anything going red.

isolate() therefore seeds each root variable from the real home first — but only when the variable is not already exported and the default directory actually exists, which makes it a no-op on machines and CI runners that do not use that version manager. asdf and mise also read a global ~/.tool-versions and neither accepts an absolute path to it from the environment, so that one file is copied into the sandbox home.

Five self-tests in the module pin this: that every leak-prone variable is still in the list, that no override resolves inside the real home, that isolate() really applies them to a Command, and that the root-preservation pass never invents a path. They are pure path arithmetic, so they cost nothing in the binaries that pick the module up. They follow the same "ungated #[test] in a #[path] module" pattern the existing oracle_selftests in common/mod.rs uses, and for the same reason: integration-test crates never get cfg(test), so gating them would silently exclude them.

Command's environment operations are keyed by variable name and the last call for a name wins, so ordering decides who gets the final say:

1. the existing SOCKET_* / npm_config_* / YARN_* prefix scrubs run first — they iterate the parent environment and would otherwise strip the sandbox values right back out;
2. then isolate();
3. then whatever the individual test sets.

Step 3 is why the cold-cache tests keep working. Several suites deliberately pass an empty directory to prove a fresh checkout installs the patched bytes — e2e_vendor_golang_build.rs even asserts its empty GOMODCACHE stays empty afterwards. Those values are applied last, so they still win.

e2e_vendor_yarn_classic_dev_flow.rs ran its scrub in the wrong order. The scrub ends with env_remove("YARN_CACHE_FOLDER"), and the helper called it after seeding the caller's private cache — so the override was wiped and every fixture install quietly used the developer's global yarn cache. Measured: 165 files. e2e_vendor_yarn_classic_build.rs carries a comment describing having fixed exactly this; the dev-flow file, added later, kept the bug. The scrub now runs first.

The availability probes leaked more than the installs did. has_command("pnpm") looks harmless, but where pnpm or yarn is a corepack shim, pnpm --version makes corepack download the package manager — around 900 files from a single probe. has_command and has_corepack_pm are now isolated too. That has a second benefit: the probe now answers for the same environment the fixture install will run in, instead of a different one.

Method: build the test binaries normally, then run each one with HOME pointed at an empty stand-in directory and count the files in it afterwards. That proves the leak and the fix without writing to anyone's actual home. The same binaries were built from the base commit for the "before" column.

Ran — every suite this PR touches, before and after:

And the sandbox really is where it all went: the Go build cache and corepack directories under it are populated with exactly the content that used to land in the home directory.

Ran — the whole CLI integration suite on both sides, 136 test binaries each. Identical pass/fail, no status changes in either direction. One binary fails on my machine in both arms: in_process_alternate_installers's bundler leg looks for the gem under vendor/bundle/ruby/<version>/, which is the Bundler 2 layout; Bundler 1.17 puts it at vendor/bundle/. I confirmed it fails identically on the base commit with an untouched home, so it is pre-existing and unrelated.

Ran — cargo clippy --workspace --all-features --all-targets on the pinned toolchain. No new warnings from any file here. (Three pre-existing clippy findings in socket-patch-core reproduce identically on the base commit.) cargo fmt --check reports no diff in any file this PR touches.

Did not run — the Docker e2e suites and the setup matrix. Neither is affected: both already run inside containers whose home is thrown away, and the setup matrix is #142's subject.

Trade-off — the sandbox is a stable directory under the OS temp dir, not a fresh one per run. A throwaway directory would re-download the same handful of fixture packages every single time and buy no extra safety, since the sandbox is outside the home directory either way. The cost is that it persists between runs and grows to a couple of hundred megabytes, mostly the Go build cache and corepack. Note if you ever want to delete it by hand: Go writes its module cache read-only, so a plain rm -rf fails partway through with permission errors — run go clean -modcache against it first, or chmod -R u+w the tree. The module docs say so too.

Trade-off — the sandbox home means a fixture install no longer reads your ~/.npmrc. That is the intended direction (it is what makes the run reproducible), but if you install through a private registry configured only in your home npmrc, the fixture installs will now go to the public one.

Two suites still write to the home directory after this change, and the cause is not the tests: in_process_cargo_apply and in_process_remote_ecosystems_apply (~900 files each, cold). They call apply in process, and the crawler's global-prefix resolution shells out to npm / yarn / pnpm itself. Those children inherit the test process's environment, so the only fix is to set the variables on the test process rather than on a Command.

That is a real change of mechanism — this repo has already had to fix races caused by tests mutating the process environment (#135, #136) — so it does not belong in the same PR as a per-Command helper. global_packages_e2e.rs is the one place I did handle it here, and only partly: it spawns the binary as a child, so it can take COREPACK_HOME and npm_config_cache directly. It deliberately does not get the full isolate(), because resolving the real global prefixes is the entire point of that file and those come out of $HOME and PNPM_HOME. The two it does take cannot change the answer, and they take it from 907 files to 0.