GeezerVison

The suite drives a real install for every ecosystem it covers, and every one of those installs goes through a single helper, tool(). That helper already hands each leg a private cache for the toolchains the leg names by hand. Anything it does not name still comes out of the real home directory.

Corepack is the big one. The first pnpm or yarn call downloads an entire package manager into ~/.cache/node/corepack — roughly 900 files from a single invocation. cache_env::isolate() closes that and the rest of the set in one call.

Placement matters, and it is the same placement used everywhere else in #143:

Step 3 is what keeps the deliberately-cold legs cold. Several legs pass an empty cache directory on purpose, to prove a fresh checkout installs the patched bytes rather than a warm host copy of the pristine one. Those values are applied last, so they still win.

Expect hosted-e2e to be red on this PR. It was already red before this change existed, and it will stay red until the registry side clears. Please do not read it as a signal about this diff.

The failing leg is gem_bundler_hosted_redirect_and_known_install_defect. Bundler falls back from the compact index to the dependency API against Socket's gem patch-registry, and gets back a body it cannot unmarshal:

ArgumentError: marshal data too short

The test is written to tolerate one specific known server defect — APIResponseMismatchError — and to report anything else as a new regression. This is a different error, so the test flags it. Thirteen of the suite's fourteen legs pass.

Three runs say it is not the code:

The last green run of hosted-e2e on main was 31 July. So the code is not the variable — something moved on the server between then and now.

Unblocking the check itself is not something this PR can do. It needs either the gem patch-registry fix, or a repo admin setting the documented escape hatch (HOSTED_E2E_DISABLED = true under Settings → Secrets and variables → Actions → Variables, then re-running the failed job, and deleting the variable afterwards to re-arm).

Worth knowing before anyone suggests a path filter or an if:. The job carries explicit invariants in ci.yml, and they are there for good reasons:

So the job always runs and always lands on success or failure. The kill switch gates the steps, never the job.

Ran — cargo check --workspace --all-targets on this branch. Clean. The mod cache_env; declaration resolves because #143 supplies the file.

Ran — cargo fmt --check. No diff in this file. (Two unrelated pre-existing diffs show up in src/commands/lock_cli.rs and src/lib.rs; both reproduce on main.)

Ran — cargo clippy --workspace --all-targets. No new warnings from this file.

Did not run — the suite itself. It contacts production Socket endpoints and real package registries for every ecosystem. Driving that traffic from a laptop to verify a cache path is not a reasonable trade, so CI is the check here.

Trade-off — the sandbox is a stable directory under the OS temp dir, not a fresh one per run, so the fixture packages are not re-downloaded on every run. That is the same trade-off #143 makes and the same directory it uses; the details are in that PR.