GeezerVison

LLM Description written by Claude Code:claude-opus-5-5

Refs #823 (slice 9 of the hermetic-spawn migration). The issue stays open for the 32 remaining PENDING_RAW_SPAWNS entries.

Root cause

Ten vendor build suites spawned socket-patch with a bare Command::new and their own private SOCKET_* sweep. The copies disagreed with each other and with tests/common/hermetic.rs. Most kept an ambient SOCKET_NO_CONFIG, so SOCKET_NO_CONFIG=0 let a developer's real socket login authenticate the child. None forced the update notifier off. The maven and jvm copies re-added the opt-outs by hand, and the bun copy reused a tool scrub that also removed the forced opt-outs.

Change

• Each suite's run helper now goes through hermetic::command / hermetic_command (hermetic::binary_command for e2e_vendor_composer_crlf.rs).
• The suite-specific scrubs stay: Extra::Venv everywhere; M2_HOME for maven/jvm; the bun tool vars through scrub_ambient_bun_tool_env (the SOCKET_*-free variant made for hermetic children); every BUNDLE_* for gem via Extra::Bundle, as CI: hermetic spawns in redirect build tests (#823) #1457 did for the redirect suite; and UV_PROJECT_ENVIRONMENT for pypi via Extra::Pdm. The pypi suite's own bake_leak_guards sets that var in the test process, so before this change it reached every socket-patch child.
• The ten files leave PENDING_RAW_SPAWNS (42 -> 32), so the ratchet in spawn_env_hygiene.rs keeps them hermetic.

Files: e2e_vendor_{bun,cargo,composer,gem,golang,jvm,maven,npm,pypi}_build.rs, e2e_vendor_composer_crlf.rs, spawn_env_hygiene.rs.

Flake fix found on this PR's CI

The `coverage` job on 230c44a failed in `patch::redirect::upstream::npm::tests::project_registry_decides_a_mirrors_tarball_urls` (a file this PR doesn't otherwise touch; job). Its `from_project: false` path falls back to `SOCKET_NPM_REGISTRY`, which the `#[serial]` bun_lockb and vlt tests set to a wiremock URL. The test itself wasn't serial, so it could race them. Reproduced locally with `SOCKET_NPM_REGISTRY=http://127.0.0.1:9\` (fails), then marked the test `#[serial_test::serial]` like the `client.rs` tests that read the same var. `redirect::upstream` lib tests: 146/146.

CI cost

Only test code changes; no workflow edits. A lean PR run has the same job count (~28 Linux jobs) and about the same job-minutes (~8 min wall) before and after.

Test evidence (local, all toolchains present: cargo, go, npm, uv, composer, bundler, mvn, gradle, bun)

• cargo fmt --all -- --check: clean
• cargo clippy --locked --workspace --all-features -- -D warnings: clean
• --include-ignored per suite, no SKIP lines: composer_crlf 7/7, cargo 39/39, composer 33/33, gem 41/41, golang 36/36, npm 41/41, pypi 54/54, bun 37/37, maven 5/5, jvm 38/38, spawn_env_hygiene 15/15
• Ratchet: no_new_bare_binary_spawns would fail with "no longer spawn the binary bare" if the list entries were left in, and with "spawn the binary with a bare Command::new" if a file were reverted.

/code-review high

• Fixed: the pypi UV_PROJECT_ENVIRONMENT leak; maven/jvm now use Extra::Venv like the other suites.
• Not fixed here (behavior that predates this PR and needs new shared Extra variants, so it is out of scope for a pure migration slice): ambient PIPENV_* reaching the pypi child, COMPOSER_VENDOR_DIR / COMPOSER_HOME reaching the composer children, and vex_e2e_common::run_vex (shared by many suites) applying only Extra::Venv, so the gem VEX legs still see ambient BUNDLE_*. These are good candidates for a follow-up slice that adds Extra::Pipenv / Extra::Composer and lets run_vex take extras.
• Skipped as cosmetic: hermetic_command(&binary()) vs hermetic::binary_command() (kept the CI: hermetic spawns in redirect build tests (#823) #1457 spelling), and the bun suite's redundant --no-telemetry, which this PR didn't add.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AhV4KjRucQ3Tg5k4KMLzT1

Generated by Claude Code