wsl: prefer Linux-side git/gh over Windows interop binaries

[JonRC]

Description

When Warp runs as a Linux ELF inside WSL on Windows, WSL's default appendWindowsPath = true (in /etc/wsl.conf) puts directories like /mnt/c/Program Files/Git/cmd/ on PATH. That makes a bare Command::new("git") (or "gh") potentially resolve to the Windows .exe through WSL interop. The interop call is dramatically slower (cross-OS), can mishandle Linux paths, and breaks Linux-side hooks (e.g. LFS). Affected features include the GitDiffStats context chip, code-review per-file diffs, branch detection, file-search status, AI skill resolution, and passive suggestions.

This PR adds a small warp_util::wsl module with three cached helpers:

• is_wsl() — the existing /proc/sys/fs/binfmt_misc/WSLInterop probe, deduplicated from two prior copies in crates/warpui/src/platform/linux/mod.rs and app/src/crash_reporting/linux.rs.
• git_binary() / gh_binary() — return the literal program name on non-WSL, and on WSL walk PATH while skipping any entry under /mnt/, returning the first Linux-side executable match. If nothing is found on a filtered PATH the helper logs once and falls back to the literal name (so behavior is no worse than before).

Every Warp-internal Command::new("git"|"gh") site is rewired through the helpers, including the test/debug helpers under integration_testing/, the snapshot tests, and crates/integration/src/test/code_review.rs. The /mnt/* filter mirrors the existing precedent at app/src/terminal/model/session/command_executor/wsl_command_executor.rs:60-65 used for compgen.

User-typed shell git invocations are unchanged — those remain governed by the user's shell PATH.

Linked Issue

Tracks #8410. The issue is currently labeled enhancement without ready-to-spec / ready-to-implement. The change here is a behavior fix for an existing feature rather than new functionality, so I'd appreciate maintainers / Oz triaging it as a bug fix; happy to file a separate bug report and re-link if a fresh issue is preferred.

Other open WSL issues likely fixed by this PR

These reports describe symptoms of the same root cause (Warp-internal git falling through to git.exe via WSL interop). Maintainers may want to verify and close them once this lands:

• #7909 — Git repository detection not working on WSL (bug, ready-to-implement): the "git changes" button fails to surface diffs because the underlying git diff invocation goes through git.exe.

• #6645 — Git Repositories not detected for @ attachment in WSL (bug, ready-to-implement): the @ menu stays disabled because git ls-files (now rewired through git_binary() in app/src/ai/agent_sdk/driver/snapshot.rs and app/src/ai/skills/resolve_skill_spec.rs) fails under WSL interop.

• The linked issue is labeled ready-to-spec or ready-to-implement.

• No UI changes; screenshots/videos N/A.

Screenshots / Videos

Not applicable — change is entirely in subprocess invocation plumbing.

Testing

• New unit tests in crates/warp_util/src/wsl_tests.rs cover the pure resolver resolve_binary_in_wsl_safe_path across 8 cases: WSL prefers Linux-side dirs over /mnt/...; non-WSL passes through; only-/mnt falls back to None; user-local bin is found via PATH walk; symlinks resolve; non-executables are skipped; PATH=None is safe; non-UTF-8 PATH bytes don't panic.
• Locally verified: cargo fmt --all -- --check, cargo check and cargo clippy --all-targets --tests -- -D warnings for warp_util, warpui, warp, and integration; full cargo test -p warp_util (66 tests + 3 doc tests, all green). Full-workspace clippy/nextest weren't run on my machine because of an unrelated missing system dep (libasound2-dev).
• Manual end-to-end check: in WSL, build and run inside a git repo with both /usr/bin/git and Windows git on PATH; the GitDiffStats chip and code-review diff view continue to work, and the [GIT OPERATION] debug logs no longer warn.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

[cla-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @JonRC on file. In order for us to review and merge your code, each contributor must visit https://cla.warp.dev to read and agree to our CLA. Once you have done so, please comment @cla-bot check to trigger another check.

[oz-for-oss]

@JonRC

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I completed the review and no human review was requested for this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

Overview

This PR centralizes WSL detection in warp_util and routes Warp-internal git/gh subprocess creation through helpers that prefer Linux-side binaries under WSL.

Concerns

• The new helper also resolves and caches an absolute binary path on non-WSL hosts, which conflicts with the stated literal-name fallback and can bypass existing call-site PATH overrides.

Verdict

Found: 0 critical, 1 important, 0 suggestions

Request changes

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[cla-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @JonRC on file. In order for us to review and merge your code, each contributor must visit https://cla.warp.dev to read and agree to our CLA. Once you have done so, please comment @cla-bot check to trigger another check.

[JonRC]

Thanks for the review! Addressed in fce8b74:

resolve_or_warn now short-circuits when is_wsl() is false and returns the bare program name, so Command::new performs its normal PATH lookup at spawn time — restoring the per-call cmd.env("PATH", …) override behavior that callers like run_git_command_with_env (LFS hooks) and run_gh_command (Homebrew gh on macOS) depend on. Module docs updated accordingly. The pure resolver and existing tests are unchanged; the WSL-only path is exercised explicitly with is_wsl=true.

/oz-review

[oz-for-oss]

@JonRC

I'm re-reviewing this pull request in response to a review request.

You can view the conversation on Warp.

I reviewed this pull request and requested human review from: @vorporeal.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[JonRC]

@cla-bot check

[cla-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @JonRC on file. In order for us to review and merge your code, each contributor must visit https://cla.warp.dev to read and agree to our CLA. Once you have done so, please comment @cla-bot check to trigger another check.

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[JonRC]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

Oz no longer requests changes for this pull request after the latest automated review.

[oz-for-oss]

Overview

This PR centralizes WSL detection in warp_util::wsl, adds cached WSL-safe git/gh binary resolution, and rewires Warp-internal subprocess invocations to avoid Windows interop binaries when a Linux-side executable is available. The added resolver tests cover the main PATH filtering, fallback, symlink, executability, and non-UTF-8 PATH cases.

Concerns

No blocking correctness or security concerns found in the annotated diff.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[vorporeal]

thanks for the PR! some thoughts:

at a high level, i'm concerned that "leaking" this detail to invokers of Command will make it too easy for someone to fail to use this at a future call site.

if we want to always be doing this additional logic when using Command and BlockingCommand, should this be an implementation detail of those wrappers? i.e.: we still call Command::new("git") but internally, it uses your helper functions to perform the translation, when needed.

[vorporeal]

this dependency edge is in the wrong direction - the UI framework shouldn't be dependent on "app code". (in general, warp_-prefixed crates should all sit above the UI framework. also, as time goes on, i'm not loving the warp_util grab-bag crate, so i'm generally trying to avoid putting new things in there.)

given warpui already depends on command (on non-macOS platforms), if you agree that we should move the git/gh resolution logic into the command crate, i'd say we also move the is_wsl() function in there. (it's not my favorite home for that function, but i also don't necessarily feel like making a wsl crate just to hold is_wsl() is necessary.)

[JonRC]

Thanks @vorporeal! Both points make a lot of sense — the "every new call site has to remember the helper" risk is real, and the dep direction critique on warpui → warp_util is fair. I'll move the WSL detection and the git/gh resolution into the command crate so Command::new("git") / BlockingCommand::new("git") transparently do the right thing, drop the new module from warp_util entirely, and have warpui::platform::linux::is_wsl() delegate into command. Will push and ping you once it's done.

[JonRC]

@vorporeal — addressed in a811077:

• The WSL detection + git/gh resolution now live in crates/command/src/wsl.rs. command::r#async::Command::new / command::blocking::Command::new (plus new_with_session / new_with_process_group) call an internal translate_program_for_spawn so call sites continue to write Command::new("git") and the substitution happens automatically — no per-callsite remembering.
• Only bare-name programs in KNOWN_NAMES = ["git", "gh"] are touched; path-qualified or unknown programs pass through unchanged, so any caller that already specified /usr/bin/git is preserved.
• The new warp_util::wsl module is gone — every previous warp_util::wsl::git_binary() / gh_binary() callsite reverted to bare Command::new("git" | "gh"). The warpui → warp_util and integration → warp_util Cargo edges are gone with it.
• warpui::platform::linux::is_wsl() and app::crash_reporting::linux now delegate to command::wsl::is_wsl(). Dep direction is warpui → command (which already existed on non-macOS) and app → command — no warp_* crate depending on warp_util for this.
• 11 unit tests live alongside the new module: 8 cover the pure resolver, 3 cover the bare-name detector (recognizing git/gh, skipping paths, skipping unknowns).

Local checks (touched crates): cargo fmt --check, cargo clippy --all-targets --tests -- -D warnings, and cargo test for command, warp_util, warpui, warp, and integration all green.