fix(env): scrub GIT_* discovery vars from for-each and --execute fallback

[max-sixty]

#3374 scrubbed inherited GIT_* discovery vars from user-hook spawns, but two more spawn sites relocate a user command into a wt-chosen worktree and had the same bug: wt step for-each and the --execute payload when wt executes it directly (no shell integration — including every !wt-alias invocation, which bypasses the wrapper). Git resolves GIT_DIR/GIT_WORK_TREE before walking up from the cwd, so the inherited value silently overrode the worktree wt placed the command in: git w step for-each -- git rev-parse --show-toplevel from a linked worktree printed the invoking worktree's path for every iteration while the headers named each worktree. The linked-worktree alias case is the common trigger — git exports an absolute GIT_DIR pinned to the invoking worktree's private gitdir there (verified on git 2.54; from a main-worktree root it exports none).

The rule is now stated once, on scrub_git_discovery_env_vars: scrub exactly when wt chose the child's cwd (hooks, for-each, the --execute fallback); keep when the command runs in the user's own context (aliases, commit.generation, and wt's internal plumbing, which keeps the absolutize-and-forward behavior from #1914). A CLAUDE.md rule points there, mirroring the CommandTrace any-new-spawn-site convention.

Testing: regression tests for both new scrub sites (each validated by reverting the fix and watching it fail) plus an alias pass-through test pinning the keep side. The --execute test is cross-platform, so Windows CI drives the non-unix spawn variant and unix the exec variant; the for-each test follows the file's unix sh -c precedent.

Ref #3373 (already closed by #3374; this completes the sweep).

This was written by Claude Code on behalf of max-sixty

🤖 Generated with Claude Code

[worktrunk-bot]

The change looks correct and well-scoped. The gating is exactly right: target_dir is only set by change_directory(), so target_dir.is_some() precisely means "wt chose the child's cwd" — the same condition that governs the hook and for-each scrubs. Both platform variants of execute_command apply it consistently, and the keep-side sites (aliases, commit.generation, internal Cmd plumbing) are left untouched, matching the classification now centralized on scrub_git_discovery_env_vars. I confirmed the "completes the sweep" claim: the fourth relocating site, the background pipeline runner, already scrubs (run_pipeline.rs spawn_shell_command), so hooks / for-each / --execute fallback / pipeline are now uniformly covered. Tests are thorough — both scrub-side regressions plus the alias pass-through pin the keep side.

Not approving only because of the red check below, which isn't this PR's fault.

The failing lint check is pre-existing and unrelated to this change. It's a lychee 404, not a formatting/clippy failure (cargo fmt and cargo clippy both pass). The dead link is https://docs.anthropic.com/en/docs/build-with-claude/claude-code in docs/content/llm-commits.md and skills/worktrunk/reference/llm-commits.md — files this PR doesn't touch — and lint also fails on the base commit on main. The Anthropic docs moved; I verified both the old URL and its redirect target now 404, while https://docs.claude.com/en/docs/claude-code/overview returns 200. That's a separate link-rot fix (main-branch CI), out of scope for this PR.

[worktrunk-bot]

codecov/patch is failing on this PR, and after investigating I believe it's a structural false positive rather than a real coverage gap — flagging it here and dismissing my auto-approval, since per CLAUDE.md a failing codecov/patch gates merge and shouldn't be rubber-stamped.

What's uncovered: the two new lines in the Unix execute_command — if target_dir.is_some() { scrub_git_discovery_env_vars(&mut cmd); } in src/output/global.rs.

Why it can't be covered on the Linux run: that function ends in cmd.exec(), which replaces the process image before llvm-cov flushes its counters, so the entire Unix execute_command body reads as uncovered — the pre-existing lines above the new ones (current_dir/stdin/stdout/stderr setup) are in the same miss list in the coverage artifact. The new lines just extend an already-uncoverable function.

The path is tested — test_switch_execute_fallback_does_not_inherit_git_discovery_vars drives wt switch feature --execute … as a subprocess and asserts the payload sees empty GIT_DIR/GIT_WORK_TREE. It genuinely exercises the scrub; the subprocess's counters just die with the exec(). On non-Unix the same test drives the spawn variant (which does register), but the coverage run is Linux-only, so codecov never sees that side.

The repo has no coverage-exclusion convention (GRCOV_EXCL / #[coverage(off)] etc.), so there's no in-tree way to mark these lines. Options if you want green: pull the if target_dir.is_some() decision into a small helper that a unit test can call directly (coverable), or ignore codecov/patch here as a known exec-path artifact. Since CLAUDE.md requires explicit maintainer approval to merge over a failing codecov/patch, this is your call.

The change itself still looks correct and well-scoped (my earlier review stands) — this is purely about the coverage gate.

codecov/patch failing — dismissing auto-approval per CLAUDE.md; it's a structural exec-path false positive (analysis in follow-up comment), merge decision is the maintainer's.