[worktrunk-bot]

Opened at @max-sixty's request in #3021 (comment) — make running/regenerating tests robust to the contributor's local environment so nobody has to match CI's GIT_* setup.

The problem

insta_cmd records every env var a test command sets or removes — Rust's Command::env_remove registers in get_envs(), and insta-cmd serializes a removal as KEY: "". isolate_subprocess_env scrubs whichever GIT_* / WORKTRUNK_* keys exist in the parent environment, so the recorded env: block depends on the host:

• CI has GIT_EDITOR set → GIT_EDITOR: ""
• A contributor's box might have GIT_PAGER → GIT_PAGER: "", or neither, or both

This is what bit #3021: help_list_long.snap / help_list_narrow_80.snap were regenerated on a box with GIT_PAGER and picked up GIT_PAGER: "" instead of CI's GIT_EDITOR: "".

Note this is cosmetic, not a CI failure: insta's matches_fully compares only the snapshot body (self.contents == other.contents), never the info:/env: metadata. But the spurious machine-to-machine diff is exactly what makes contributors think they have to match CI's environment.

The fix

A dynamic .env redaction in add_standard_env_redactions (strip_host_scrubbed_env_markers) drops every empty-valued GIT_* / WORKTRUNK_* entry from the recorded block. It runs as its own pass after the per-key .env.* redactions, so affirmatively-set vars (config paths → [TEST_CONFIG], coverage → [LLVM_PROFILE_FILE]) already hold non-empty placeholders and are kept. The explicitly-named unconditional scrubs (NO_COLOR, SHELL, PSModulePath) are host-independent and left intact.

Result: regenerating on any machine produces the same env: block, regardless of the contributor's GIT_* environment.

Why no snapshots are regenerated

The info: block is never compared, so a metadata-only difference never triggers a rewrite — even INSTA_UPDATE=always leaves an unchanged-body snapshot alone. Existing committed snapshots keep their (now-redundant) markers until their body next changes, at which point the rewrite drops them cleanly. This avoids a disruptive ~1000-file cosmetic diff that would conflict with every in-flight snapshot PR; the robustness applies to all future regenerations from this point on.

If you'd prefer the tree uniform now, a follow-up cargo insta test --accept bulk regen is a clean separate commit — happy to push it.

Verification

• New unit test strip_host_scrubbed_env_markers_normalizes_env_block covers drop/keep/passthrough.
• Confirmed end-to-end: deleting help_list_long.snap and forcing a fresh write drops GIT_EDITOR: "" while keeping NO_COLOR/SHELL/PSModulePath and the "0"-valued WORKTRUNK_TEST_* vars.
• help (57), snapshot_formatting_guard (6), and ci_status (68) snapshot suites pass; cargo fmt --check and cargo clippy --tests --all-features clean.

🤖 Generated with Claude Code

[worktrunk-bot]

One observation on the "affirmatively-set vars are kept" framing — it has a real counterexample in the existing suite. Not a correctness issue (insta never compares the info: block), but worth tightening the comment/doc since a future regen will silently drop a documented test input. Detail inline.

[worktrunk-bot]

The predicate is "empty-valued GIT_* / WORKTRUNK_*", but that also matches affirmatively-set empty values — not just env_remove scrub markers. In the recorded YAML the two are indistinguishable (both serialize as KEY: ""), so the strip pass can't separate them.

Concrete case: test_list_config_env_override_validation_failure sets WORKTRUNK_WORKTREE_PATH="" — the empty value is the test's subject (it triggers worktree-path cannot be empty). It's recorded as WORKTRUNK_WORKTREE_PATH: "" in the committed list_config_env_override_validation_failure.snap env block, and it's host-independent (deterministic on every machine), so it's not the churn this PR targets. After this change, the next regen of that snapshot drops it — and since the body doesn't show which input produced the warning, the env block was the only place documenting it.

Harmless to the comparison, but the claim here (and the matching lines in tests/CLAUDE.md) reads as if affirmatively-set vars always survive. Worth a sentence noting that affirmatively-set empty GIT_* / WORKTRUNK_* vars are dropped too (indistinguishable from scrub markers), with WORKTRUNK_WORKTREE_PATH as the known case.

[max-sixty]

@worktrunk-bot please fix

[worktrunk-bot]

Fixed in 6ab6422. The strip pass keys on the empty value, so a scrub marker and an affirmatively-set empty GIT_* / WORKTRUNK_* var are indistinguishable (both serialize as KEY: "") and both get dropped.

Tightened the framing in three places: the add_standard_env_redactions comment now says affirmatively-set non-empty vars are kept and carries a caveat naming WORKTRUNK_WORKTREE_PATH="" (from test_list_config_env_override_validation_failure) as the known affirmatively-set-empty case; the strip_host_scrubbed_env_markers docstring notes the same; and the matching paragraph in tests/CLAUDE.md spells out that its committed WORKTRUNK_WORKTREE_PATH: "" line stays until the body next changes, then the regen drops it — harmless since the env: block is never compared.