fix(Windows): Command resolution for executables

[john-trieu-nguyen]

Some commands on Windows would fail when the actual executable has an extension (e.g npm.cmd).

This fails:
fnox exec -- npm install
This works:
fnox exec -- npm.cmd install

Update commands to use Which for better path resolution.
Now npm install works as expected.

[greptile-apps]

Greptile Summary

This PR fixes Windows command resolution by using which::which to resolve executables (e.g., npm → npm.cmd) in three execution paths: exec.rs, edit.rs, and mcp_server.rs. The fix is guarded behind #[cfg(windows)] / #[cfg(not(windows))] blocks, leaving non-Windows behavior unchanged, and falls back gracefully to the original command name when resolution fails.

Confidence Score: 5/5

Safe to merge — no P0/P1 issues; previous compilation concerns have been addressed.

All three changed sites correctly define the cmd_name binding, guard which::which calls behind #[cfg(windows)], preserve the fully-qualified tokio::process::Command in mcp_server.rs, and fall back gracefully when resolution fails. No remaining blocking issues.

No files require special attention.

Important Files Changed

Filename	Overview
src/commands/exec.rs	Introduces cmd_name binding and Windows-only which::which resolution before Command::new; logic is correct and compiles cleanly on both platforms.
src/commands/edit.rs	Applies the same Windows-specific which resolution pattern for the editor executable; fallback to the original string is correct.
src/mcp_server.rs	Same which resolution added before tokio::process::Command::new; fully-qualified form retained, so no import issue.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["User runs: fnox exec -- npm install"] --> B{"Platform?"}
    B -- "Windows" --> C["which::which('npm')"]
    C -- "Found" --> D["cmd_path = PathBuf (e.g. npm.cmd)"]
    C -- "Not found" --> E["cmd_path = 'npm' (original fallback)"]
    B -- "Non-Windows" --> F["cmd_path = 'npm' (unchanged)"]
    D --> G["Command::new(cmd_path)"]
    E --> G
    F --> G
    G --> H["Spawn process with secrets injected"]

Loading

_{Reviews (5): Last reviewed commit: "[autofix.ci] apply automated fixes" | Re-trigger Greptile}

[gemini-code-assist]

Code Review

This pull request implements platform-specific command resolution on Windows by using the which crate to locate executables in edit.rs, exec.rs, and mcp_server.rs. The review feedback recommends using #[cfg(windows)] attributes instead of runtime if cfg!(windows) checks to avoid potential compilation errors on non-Windows platforms where the which dependency might be absent. Additionally, the feedback highlights that which::which is a blocking operation, which is an important consideration for the asynchronous implementation in mcp_server.rs.

[gemini-code-assist]

Using #[cfg(windows)] is generally preferred over if cfg!(windows) when calling functions from platform-specific dependencies. If the which crate is defined as a target-specific dependency in Cargo.toml (e.g., only for Windows), the current code will fail to compile on other platforms because the compiler still checks the inactive branch. Additionally, the logic can be simplified by avoiding redundant clones for the non-Windows case.

        #[cfg(windows)]
        let editor_path = which::which(&editor).unwrap_or_else(|_| editor.clone().into());
        #[cfg(not(windows))]
        let editor_path = &editor;

[gemini-code-assist]

Consider using #[cfg(windows)] to ensure that the which crate call is only compiled on Windows. This avoids potential build failures on other platforms if which is a target-specific dependency. The suggested refactoring also simplifies the command initialization by separating the path resolution from the Command construction.

        #[cfg(windows)]
        let cmd_path = which::which(cmd_name).unwrap_or_else(|_| cmd_name.into());
        #[cfg(not(windows))]
        let cmd_path = cmd_name;
        let mut cmd = Command::new(cmd_path);

[gemini-code-assist]

In an async context, which::which is a blocking I/O operation that can stall the Tokio executor thread. While the impact may be low for this specific tool, it's a best practice to use tokio::task::spawn_blocking for filesystem lookups in high-performance async applications. At a minimum, switching to #[cfg(windows)] is recommended to avoid compilation issues on non-Windows platforms if which is a conditional dependency.

        #[cfg(windows)]
        let cmd_path = which::which(cmd_name).unwrap_or_else(|_| cmd_name.into());
        #[cfg(not(windows))]
        let cmd_path = cmd_name;
        let mut cmd = tokio::process::Command::new(cmd_path);