test(isolation): scan the resolvers for the variables they name

[KuSh]

Follow-up to #4038, where @TaKO8Ki pointed out that the new tests pinned only HOME and should pin the other directory variables the way tests/hook_warning_scope_test.rs does. That was right, and it raised the question of what stops the next one slipping through.

Mostly, something already does. every_variable_rtk_reads_is_redirected_for_a_child scans the source for every read through the accessors, refuses any whose name it cannot resolve to a literal, and asserts each one is removed, pinned to a fixed value, or pinned inside the scratch directory. A variable rtk learns to read tomorrow fails the suite until it is redirected.

With one gap: the scan continues on the three RESOLVERS files. The exemption earns its place — a resolver defines the accessors, so user_env::var_os(name) names no variable — but it is all-or-nothing, so a literal read in one is invisible. src/core/user_dirs.rs is in that list, and it is the module for resolving user locations, which makes it the most likely place for the next agent home or path override to be written.

Measured

Adding a read of a new FUTUREAGENT_HOME, redirected nowhere, and running every_variable_rtk_reads_is_redirected_for_a_child:

the new read is in	before	after
src/hooks/init/mod.rs	FAILS — src/hooks/init/mod.rs: FUTUREAGENT_HOME	FAILS
src/core/user_dirs.rs	passes	FAILS — src/core/user_dirs.rs: FUTUREAGENT_HOME

Fix

Forgive the forwarding rather than the file: an unresolvable name is allowed in a resolver and still refused everywhere else, and a literal is collected wherever it appears. only_user_dirs_resolves_user_locations keeps its own use of RESOLVERS unchanged — there the exemption is correct, since those files are the chokepoint.

No new exemptions were needed: the only accessor read in a resolver today is that one forwarding call.

Not covered

Variables read by a dependency rather than by rtk — dirs consulting XDG_DATA_HOME, or APPDATA/USERPROFILE on Windows. redirect_rtk_data pins those, but no scan of rtk's own source can see them, so a change inside dirs would not fail anything. Catching that needs a check on the symptom instead of the source (assert a spawned child wrote nothing outside the scratch directory), which is a larger piece of work than this.

I also tried the blunter version first — env_clear() on the child plus a keep-list, so an unknown variable is absent by construction. It fails every_variable_rtk_reads_is_redirected_for_a_child and only_user_dirs_resolves_user_locations, because it replaces a guard that fails loudly at the source with a silent keep-list. Not worth the trade.

Gate

cargo fmt --all clean, cargo clippy --all-targets clean, cargo test --all 4161 passed / 0 failed, Windows cross-check clean.

🤖 Generated with Claude Code

[rtk-wshm-sync-bot]

wshm · Automated triage by AI

📊 Automated PR Analysis

📋 Type	test
🟢 Risk	low

Summary

This PR tightens an isolation test guard so that resolver files (like src/core/user_dirs.rs) are no longer wholesale exempted from the scan that checks every environment variable read is redirected for child processes; now only unresolvable names (forwarding calls) are forgiven in resolvers, while literal variable reads anywhere, including in resolvers, are still caught. It's a follow-up to PR #4038 addressing a review comment about test coverage gaps.

Review Checklist

• Tests present
• Breaking change
• Docs updated

---

Analyzed automatically by wshm · This is an automated analysis, not a human review.