GeezerVison

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

Refs #823 (slice 11 of the hermetic-spawn migration). The issue stays open for the remaining PENDING_RAW_SPAWNS entries (26 after this PR; #1488 has landed and main is merged in).

Root cause

The three VEX test commons each started the socket-patch child with a bare Command::new and a private SOCKET_* sweep that had drifted from tests/common/hermetic.rs:

• None of them forced SOCKET_NO_UPDATE_CHECK=1, and vex_pdm_hatch_common::cli / vex_pipenv_pip_common::cli actively removed an ambient one, so a child could fetch release metadata from real GitHub.
• None removed the flag-bound vars by name, so one set in-process after the sweep would reach the child, and none had the hostile seeds that make a dropped scrub fail loudly.
• vex_e2e_common/uv.rs folded SOCKET_* into its python scrub, so the same function served both the binary and the uv / python / pip children.

Change

• uv.rs::socket_patch, vex_pdm_hatch_common::cli and vex_pipenv_pip_common::cli now start from hermetic::command (reached through crate::vex_e2e_common::hermetic, which every includer already loads) and keep only their own scrubs: python / uv / pip config for the uv helper, VIRTUAL_ENV via Extra::Venv for all three, plus PDM_* / UV_PROJECT_ENVIRONMENT via Extra::Pdm for the PDM/Hatch helper and PIPENV_* / WORKON_HOME for the Pipenv helper.
• In uv.rs, scrub_python_env no longer sweeps SOCKET_* (it runs after the builder and would otherwise remove the opt-outs it forces on). The uv / python / pip children call the new scrub_tool_env (hermetic::scrub_socket_vars + scrub_python_env), so they lose nothing.
• The three files leave PENDING_RAW_SPAWNS (29 -> 26 on main), so the ratchet in spawn_env_hygiene.rs keeps them hermetic. CI: hermetic spawns in vlt test commons (#823) #1488 removed the adjacent vlt_* lines; the merge of main resolves that list conflict by dropping all six.

CI cost

Test code only, no workflow edits. A lean PR run keeps the same job count (~29 Linux jobs) and job-minutes (~31 job-min, ~8 min wall) before and after.

Test evidence (local)

• Red: with the three list entries removed and the helpers reverted, spawn_env_hygiene::no_new_bare_binary_spawns fails, naming exactly these three files. Green with the change.
• cargo fmt --all -- --check: clean. cargo clippy --locked --workspace --all-features -- -D warnings (the CI command): clean.
• Every test target that includes one of these commons: e2e_vex_lockfile 346 passed (drives the PDM / Hatch / Pipenv / pip cli()), e2e_hosted_production 49, e2e_vendored_production 49, e2e_vendor_pypi_build 47, e2e_redirect_uv_build 13, spawn_env_hygiene 15. 0 failed.
• Real uv (ignored legs, SOCKET_PATCH_UV_E2E_REQUIRED=1 so a skip is a failure): e2e_redirect_uv_build manifestless_vex 9/9 passed and e2e_vendor_pypi_build manifestless_vex 7/7 passed. These drive uv.rs::socket_patch and every scrub_tool_env child.

/code-review high

• Fixed: the PDM/Hatch cli() now also applies Extra::Pdm, so an ambient PDM_* or UV_PROJECT_ENVIRONMENT can't move the venv the crawler reads (e2e_vex_lockfile 346/346 again after the change).
• Not fixed here (pre-existing, unchanged by this slice; candidates for a later one):
  • The Pipenv/pip cli() still lets UV_PROJECT_ENVIRONMENT, PDM_*, PYTHONUSERBASE, CONDA_PREFIX through, and HATCH_* reaches the PDM/Hatch one. Both old sweeps had the same gap.
  • uv.rs::scrub_python_env and the Pipenv PIPENV_* sweep could become shared Extra::Python / Extra::Pipenv variants in hermetic.rs.
  • The uv capability probes (uv --version, help_has, pip lock --help) spawn unscrubbed, as before.
  • scrub_tool_env walks the environment twice per spawn. That's negligible next to a uv run.

🤖 Generated with Claude Code

https://claude.ai/code/session_015HUYJe1zS1wZnLys72fnxx

Generated by Claude Code