fix(scanner): keep explicit-home scans isolated on Windows - #916
Conversation
Keep Windows config and Zed known-folder discovery behind use_env_roots so an explicit --home scan cannot fall through to the process APPDATA or LOCALAPPDATA profile. Evaluate extra-path warnings against the supplied scan home while preserving default environment-aware discovery and warn-only behavior. Tighten the existing regressions around disabled environment roots and supplied-home boundaries.
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: df88443780
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| #[cfg(target_os = "windows")] | ||
| if let Some(dir) = dirs::config_dir() { | ||
| return dir.join("tokscale").to_string_lossy().into_owned(); |
There was a problem hiding this comment.
Use the supplied Windows roaming config root
On Windows explicit --home calls set use_env_roots = false, so this dirs::config_dir() branch is now skipped and PathRoot::Config falls through to {home}/.config/tokscale. The CLI's explicit-home settings resolver uses {home}/AppData/Roaming/tokscale/settings.json for ExplicitHomeConfigLayout::WindowsRoaming, and default writers use the roaming config root, so Antigravity/Trae/Warp cache scans for another Windows profile will look in the wrong directory. Please keep the process %APPDATA% lookup gated, but add a supplied-home AppData/Roaming/tokscale fallback when env roots are disabled.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
The explicit-home branch now derives AppData/Roaming/tokscale from home_dir, matching ExplicitHomeConfigLayout::WindowsRoaming; the process dirs::config_dir() lookup remains limited to environment-root scans. The regression now selects the platform-specific expected root.
| } | ||
| #[cfg(target_os = "windows")] | ||
| if result.zed_db.is_none() { | ||
| if use_env_roots && result.zed_db.is_none() { |
There was a problem hiding this comment.
Probe supplied-home AppData for Zed
With explicit --home on Windows, use_env_roots is false, so this new guard skips the only Windows Zed location. The earlier probe is {home}/.local/share/zed/threads/threads.db, while the Zed parser documents the Windows database under %LOCALAPPDATA%\Zed\threads\threads.db; unlike Hermes and Crush, there is no {home}/AppData/Local/Zed/... fallback. This makes reports for another Windows profile drop Zed usage unless the user manually configures an extra path; gate only the process known-folder lookup and still probe the supplied home's AppData/Local path.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Explicit-home scans now probe <home>/AppData/Local/Zed/threads/threads.db; default scans continue using dirs::data_local_dir(). A direct supplied-home regression was added, and the independent extra-path fixture now uses custom-zed/threads.
There was a problem hiding this comment.
1 issue found across 2 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="crates/tokscale-core/src/scanner.rs">
<violation number="1" location="crates/tokscale-core/src/scanner.rs:17">
P3: Explicit-home scans can emit a misleading warning: the check uses the supplied scan home, while the message still claims the path is outside `$HOME`. Wording such as “outside the scan home” would match the new behavior and the `home=` field.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| } | ||
| /// Emit a one-time `tracing::warn!` if `path` does not start with the scan's | ||
| /// supplied home directory. The scan is NOT blocked — this is a heads-up only. | ||
| fn warn_if_escapes_home(home: &Path, client_id: ClientId, path: &Path) { |
There was a problem hiding this comment.
P3: Explicit-home scans can emit a misleading warning: the check uses the supplied scan home, while the message still claims the path is outside $HOME. Wording such as “outside the scan home” would match the new behavior and the home= field.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At crates/tokscale-core/src/scanner.rs, line 17:
<comment>Explicit-home scans can emit a misleading warning: the check uses the supplied scan home, while the message still claims the path is outside `$HOME`. Wording such as “outside the scan home” would match the new behavior and the `home=` field.</comment>
<file context>
@@ -12,18 +12,16 @@ use crate::sessions::{normalize_workspace_key, workspace_label_from_key};
- }
+/// Emit a one-time `tracing::warn!` if `path` does not start with the scan's
+/// supplied home directory. The scan is NOT blocked — this is a heads-up only.
+fn warn_if_escapes_home(home: &Path, client_id: ClientId, path: &Path) {
+ if !path.starts_with(home) {
+ tracing::warn!(
</file context>
Resolve config clients and Zed from the supplied profile AppData roots when environment roots are disabled. Keep process APPDATA and LOCALAPPDATA known-folder lookups limited to default environment-aware scans. Pin the Windows roaming layout contract, add a direct supplied-home Zed regression, and move the independent Zed extra-path fixture off the newly canonical default path.
Fixes #915
Summary
use_env_roots, so explicit-home scans resolve to<supplied-home>/AppData/Roaming/tokscaleinstead of the process%APPDATA%.use_env_rootswhile probing<supplied-home>/AppData/Local/Zed/threads/threads.dbfor explicit-home scans.Current-upstream adaptation
%APPDATA%PathRoot::Config::resolve_with_env_strategyand the CLI's existingExplicitHomeConfigLayout::WindowsRoamingcontractdirs::config_dir()insideuse_env_roots; otherwise deriveAppData/Roaming/tokscalefrom the supplied home%LOCALAPPDATA%scan_all_clients_with_env_strategy_innerAppData/Localpath when environment roots are disabled; retain the process known-folder lookup for default scanswarn_if_escapes_homeand its settings/environment callersPath::new(home_dir)explicitlyuse_env_roots = trueThe Windows downstream validation established the isolation invariant recovered into TokenBar PR #59: explicit-home scans must not consume process-profile roots. This PR maps that invariant to current upstream and uses Tokscale's existing Windows roaming/local explicit-home layouts for the positive supplied-profile paths. The validation ancestry and full downstream evidence are recorded in the handoff comment.
Verification
cargo test -p tokscale-core test_path_root_config_ignores_env_when_disabled -- --test-threads=1cargo test -p tokscale-core test_scan_all_clients_with_scanner_settings_discovers_zed_windows_local_appdata_home -- --test-threads=1cargo test -p tokscale-core test_scan_all_clients_with_scanner_settings_merges_zed_extra_threads_db -- --test-threads=1cargo test -p tokscale-core test_parse_local_clients_honors_scanner_extra_scan_paths_for_zed_threads_db -- --test-threads=1cargo test -p tokscale-core test_extra_scan_path_outside_home_does_not_block_scan -- --test-threads=1cargo test -p tokscale-core test_scan_all_clients_ignores_extra_dirs_when_env_roots_disabled -- --test-threads=1cargo test -p tokscale-cli explicit_home_config_path_uses_windows_roaming_layout -- --test-threads=1cargo fmt --all -- --checkcargo clippy --locked --workspace --all-features -- -D warningscargo test --workspace --all-featurescargo build --release -p tokscale-clibun run --cwd packages/frontend test -- __tests__/lib/clientRegistry.test.tsbun run --cwd packages/frontend typecheckgit diff --checkWindows evidence boundary
The downstream fixes were executed and validated on Windows for the process-profile exclusion invariant. This PR maps that invariant to current upstream and derives the positive supplied-profile paths from Tokscale's existing Windows layout contracts. Upstream
Build Nativeverifies Windows x64 and arm64 compilation only; it does not run the Rust tests. Unless an additional Windows runner executes them, this PR does not claim independent upstream Windows runtime verification.