test(agents): make shell-exec tool tests run on Windows#508
Conversation
ShellExecTool spawns an executable directly (Command::new(command).args), with no implicit shell. The tests drove it with POSIX commands — `echo`, `sh`, `ls` — which on Windows are cmd builtins with no .exe (`echo`, `ls`) or absent entirely (`sh`), so the spawn failed and six tests errored once Xoshbin#499 made the suite runnable on Windows. Route the shell-dependent cases through the host shell (`cmd /C` on Windows, `sh -c` elsewhere) via a SHELL constant, with per-platform spellings where the syntax differs (`1>&2` vs `>&2`, `dir /B` vs `ls`). The args-omitted case uses `hostname` — a real no-arg executable present on all three platforms — so it still exercises the "args absent → runs" path without a shell. No product change; ShellExecTool's direct-exec contract is unchanged. Clears the last of the 38 Windows failures surfaced by Xoshbin#499 (see Xoshbin#498). Independent of Xoshbin#500, which only touches the frontend agents UI, not this Rust tool. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MGJAx66y29o33szDvVYTBH
There was a problem hiding this comment.
Code Review
This pull request improves the cross-platform compatibility of the ShellExecTool tests in shell_test.rs, specifically targeting Windows support. It introduces a conditional SHELL constant (cmd /C on Windows and sh -c on other platforms) and updates several test cases to use this constant. It also adapts platform-specific command behaviors, such as stderr redirection and directory listing, and replaces the echo command with hostname to test omitted arguments using a standard executable. There are no review comments, and I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
The last of the 38 Windows test failures surfaced once #499 made
cargo testloadable on Windows (context in #498). Test-only — no product change.The failures
ShellExecToolspawns an executable directly (Command::new(command).args(...)), with no implicit shell — a deliberate design (no shell-injection surface). Six tests drove it with POSIX commands (echo,sh,ls), which on Windows are cmd builtins with no.exe(echo,ls) or absent entirely (sh), so the spawn failed:invoke_runs_simple_command,invoke_returns_exit_code_zero_on_success—echoinvoke_returns_non_zero_exit_code_for_failed_command,invoke_captures_stderr—sh -c …invoke_runs_in_cwd—lsinvoke_treats_args_as_omitted_when_missing— bareechoThe fix
Route the shell-dependent cases through the host shell —
cmd /Con Windows,sh -celsewhere — via aSHELLconstant, with per-platform spellings where the syntax differs (echo err 1>&2vs>&2;dir /Bvsls). The args-omitted case now useshostname, a real no-arg executable present on Windows/macOS/Linux, so it still exercises the "args key absent → runs" path without a shell.ShellExecTool's direct-exec contract is unchanged — the tool still spawns exactly the executable it's given. Only the tests changed, to name the platform's shell instead of assuming POSIX binaries are on PATH.Scope
This Rust tool is not touched by #500 (which reworks the frontend agents UI under
src/built-in-features/agents/), so the fix is independent and won't collide.Verification
cargo test agents::builtin_tools::shell_test— all 12 green, including the 6 that were failing.cargo testgreen (knownfs_watcherinotify env failure aside);cargo clippy --all-targets -- -D warningsandcargo fmtclean.With #503–#507 and this PR,
cargo testnow passes on Windows in full.🤖 Generated with Claude Code