Summary

Several unit tests in src/core/telemetry.rs call the production salt / device-hash functions directly with no path override, so cargo test writes a real .device_salt to the user's data dir (~/Library/Application Support/rtk/.device_salt on macOS, ~/.local/share/rtk/.device_salt on Linux).

Reproduce (macOS)

rm -f "~/Library/Application Support/rtk/.device_salt"
git clone https://github.com/rtk-ai/rtk
cd rtk
cargo test -p rtk telemetry
ls -la "~/Library/Application Support/rtk/.device_salt"
# -> file exists, owned by your user, 64 bytes

The tests pass, but they have leaked a real salt to the test runner's host filesystem.

Affected tests

src/core/telemetry.rs:447-487:

• test_device_hash_is_stable — calls generate_device_hash()
• test_device_hash_is_valid_hex — calls generate_device_hash()
• test_salt_is_persisted — calls get_or_create_salt()

All three go through salt_file_path() → dirs::data_local_dir(), which always resolves to the user's real data dir.

Why this matters

1. Running cargo test on a fresh dev machine produces a salt that the user never consented to creating (telemetry consent is None, but the salt file is now present).
2. Hides issue bug(telemetry): salt file not auto-created on macOS — device hash shows '(no salt file)' #1656 from anyone investigating on a machine where they've run cargo test: after running the test suite, rtk telemetry status shows a real device hash and the (no salt file) symptom is gone — even though no rtk init was ever run.
3. CI runners that persist $HOME across jobs (less common, but possible on self-hosted) would leak a salt between runs.

Suggested fix shape

Inject the path. One option: have salt_file_path() accept an Option<&Path> override, default behavior unchanged but tests pass a tempfile::TempDir. Another: a RTK_DATA_DIR env var read inside salt_file_path(), set in test setup. Either way, the tests should use tempfile or equivalent so nothing leaks to the user dir.

Environment

• rtk develop HEAD (verified locally 2026-05-27)
• macOS 25.5 (Darwin), but the path leak affects every platform dirs::data_local_dir() resolves on

Relation to #1656

Tracked separately rather than bundled into PR #2105, per CONTRIBUTING.md scope rules. The two issues share an ancestor (get_or_create_salt) but have different fixes: #1656 is a status-message UX bug; this one is a test-isolation correctness bug.