fix(wsl): run the CLI bridge through the \\wsl$ script path

[innocarpe]

Description

The managed WSL CLI launcher passes wslpath -w output straight to powershell.exe -File. On Windows that path is \\wsl.localhost\<distro>\.... PowerShell's AuthorizationManager then refuses the script before the bridge starts, either with an interactive trust prompt or, noninteractively, AuthorizationManager check failed. The same script on the \\wsl$\ share runs.

Focused fix

• In scope: after wslpath -w of the bridge script, rewrite a leading \\wsl.localhost\ to \\wsl$\ and pass that path to -File.
• Out of scope: the worktree cwd UNC (-WslCwd), wslpath itself, execution policy, and any other UNC consumer.

Preserves

• A bridge path that is already \\wsl$\, or a normal Windows drive path, is left unchanged.
• The cwd passed as -WslCwd stays the modern \\wsl.localhost\ spelling.
• The historical pre-native launcher fixture is not rewritten.

Evidence

• Test: node node_modules/vitest/vitest.mjs run --config config/vitest.config.ts src/main/cli/wsl-cli-installer.test.ts
• 24 passed. The new assertion executes the generated substitution under bash: \\wsl.localhost\Ubuntu-24.04\tmp\orca-wsl-bridge.ps1 becomes \\wsl$\Ubuntu-24.04\tmp\orca-wsl-bridge.ps1.
• Not run on a Windows machine with the Group Policy that zones \\wsl.localhost\.

User-regression-tradeoffs

• Only the script path PowerShell executes changes spelling. The share is the same running distro.

Fixes #20082

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Changes how the CLI bridge script path is rewritten on Windows.

The PR appears safe to merge; no new actionable issue was identified.

Summary

The PR rewrites only the WSL bridge script path from \\wsl.localhost\ to \\wsl$\ before passing it to PowerShell. The added tests cover the rewrite and confirm that existing \\wsl$\ and drive-letter paths remain unchanged.

_{Reviews (2) · Last reviewed commit: "fix(wsl): leave an already-\\wsl$ or dri..."}

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

🧰 Additional context used

📚 Code guidelines (1)

AGENTS.md — auto-discovered

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: 12c9df64-6513-4d9c-8853-d6951657a7f0

📥 Commits

Reviewing files that changed from the base of the PR and between 3771e28dc374c795a4cefd6b0c9200fef276297d and 0f6d9f3.

📒 Files selected for processing (1)

• src/main/cli/wsl-cli-installer.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 4 remain after this review.

---

📝 Walkthrough

Walkthrough

The WSL launcher now changes the converted bridge script path from the \\wsl.localhost\ UNC prefix to \\wsl$\ before passing it to PowerShell. It does not rewrite the separately converted working-directory path. The launcher test checks the conversion and verifies that existing \\wsl$\ and drive-letter paths remain unchanged.

Priority: ➖ Normal

Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to 0f6d9

The change narrowly normalizes the bridge script path while preserving other paths. No actionable merge-blocking risk is identified; Windows Group Policy validation remains unperformed.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 0f6d9

The change is narrowly scoped to the script path and preserves the existing launcher, arguments, and execution options. No exploitable security regression was established, but the effects on Windows trust decisions have not been validated under the affected Group Policy.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The directly affected exposure is bridge execution through callers of the shared WSL launcher builder. The code preserves the distro and path suffix and requests no new elevation mechanism; Windows identity and ACL equivalence between the aliases remain unverified.

Trust Boundaries and Controls

• observed — The normalized path is passed as a quoted -File argument rather than interpolated into a PowerShell -Command expression. Working-directory and forwarded arguments remain separate, providing counterevidence to a newly introduced command-injection path from this substitution.

Hardening Proposals

• proposed — Validate the two UNC spellings on Windows under the affected enterprise policies, checking resolved script identity, effective file permissions, and AuthorizationManager outcomes. Confirm that restoring execution through the legacy alias is compatible with the intended policy boundary.

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description explains the problem, focused fix, scope, behavior, issue reference, and test evidence. However, it does not follow the repository template and omits required sections such as ELI5, Wh…	Restructure the description using the repository template. Add the missing required sections, mark Visual Proof as N/A with a reason if applicable, complete the Testing and Checklist items, and retain the existing technical explanation and …
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 2 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: routing the WSL CLI bridge through the \\wsl$ script path.
Linked Issues check	✅ Passed	Issue #20082 requires the managed WSL CLI bridge to run non-interactively when wslpath -w returns a \\\\wsl.localhost\\\\ script path. The launcher now rewrites only the bridge path prefix to `\\wsl$\…
Out of Scope Changes check	✅ Passed	The changes stay within issue #20082. They modify the managed WSL launcher and its automated test. They do not modify wslpath, execution policy, the bridge script, or the -WslCwd path. The test di…

Full details: Description check

Explanation

The description explains the problem, focused fix, scope, behavior, issue reference, and test evidence. However, it does not follow the repository template and omits required sections such as ELI5, What Changed, Why, Visual Proof, Testing checkboxes, Review, Agent skill upstream boundary, Notes, and Checklist.

Resolution

Restructure the description using the repository template. Add the missing required sections, mark Visual Proof as N/A with a reason if applicable, complete the Testing and Checklist items, and retain the existing technical explanation and test evidence.

• Fix all pre-merge checks with AI

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[pullfrog]

✅ No new issues found.

Reviewed changes

This PR works around #20082: on Windows machines whose PowerShell policy zones \\wsl.localhost\ as Internet, executing the Orca bridge with powershell.exe -File fails with AuthorizationManager check failed (or prompts interactively) before the bridge starts. The fix rewrites only the bridge script path to the legacy \\wsl$\ share, which resolves to the same running distro but is classified as intranet.

• Bridge UNC rewrite — after wslpath -w resolves the bridge path, buildLauncher rewrites a leading \\wsl.localhost\ to \\wsl$\. A path already on \\wsl$\ or a Windows drive path is left unchanged, and ORCA_WSL_CWD_WIN (passed only as -WslCwd, never executed as a script) keeps the modern spelling.
• Test coverage — the launcher test pins the exact generated rewrite line, executes it under real bash against \\wsl.localhost\Ubuntu-24.04\..., and asserts the cwd UNC is not rewritten.

I verified the change is scoped to the one script-execution path (only wsl-cli-scripts.ts emits wslpath -w), that the focused suite passes (24/24), and that oxlint/oxfmt are clean. I also confirmed the load-bearing external contract: \\wsl$ is a supported, non-deprecated compatibility alias for \\wsl.localhost (Microsoft WSL release notes Build 21354, and microsoft/WSL src/linux/init/util.cpp still defines PLAN9_RDR_COMPAT_PREFIX). The rewrite is a no-op on non-matching paths, so it cannot regress a setup where the modern spelling already worked.

Two notes for the record, neither blocking:

• The PR body says this was not validated on a real Windows host with the offending GPO; the correctness argument rests on the issue's reproduction plus the zone/spelling analysis. Worth a manual smoke test on a GPO-managed machine if one is available.
• The only documented asymmetry — \\wsl$ may not auto-start a stopped distro while \\wsl.localhost can — does not apply, because this launcher runs from inside the distro.

  ^{｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

[innocarpe]

Sync update (0f6d9f315e)

The launcher substitution is now executed for an already-\wsl$ path and for a Windows drive path. Both stay unchanged.

• Commit: 0f6d9f315e3de03cf614f260dbf9efbf52638410
• Upstream: fix(wsl): run the CLI bridge through the \\wsl$ script path #24326
• Fork portfolio: [upstream #24326] fix(wsl): run the CLI bridge through the \\wsl$ script path innocarpe/orca#285

[pullfrog]

✅ No new issues found.

Reviewed changes

This run re-reviewed the delta since the prior pullfrog review (3771e28). The only change is test-only: it closes the pass-through coverage gap raised on the greptile thread.

• Added pass-through assertions — the launcher test now builds a rewriteBridgePath helper that re-runs the generated UNC substitution under real bash for an already-\\wsl$ path and a C:\... drive path, asserting both are returned unchanged. The existing \\wsl.localhost\ rewrite assertion is untouched.

The pass-through cases can genuinely fail (they assert exact equality against the substitution's real bash output, not a loose match), and the focused suite passes 24/24 locally.

  ^{｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}