v3.46.1 — Windows browser tools no longer pass tool input through a shell

Security fix: Windows browser MCP tools

Who is affected: Windows hosts running the RuFlo browser MCP tools (browser_open, browser_fill, browser_type, browser_eval and the other browser_* tools) where agent-browser is not installed globally, so the tools fall back to npx. Every published version that carries the #2770 fallback is affected, including 3.46.0. macOS and Linux were never affected.

What was wrong: the npx fallback ran through the Windows command shell so npx.cmd could be resolved. Values supplied to the browser tools (fill text, eval scripts, selectors) were passed on that command line and could be interpreted as shell syntax.

What changed: the launcher now resolves the npm shims to the process behind them and starts it directly with an argument array. No shell is involved, and no tool value is ever parsed as a command. If the launcher cannot be resolved without a shell, the tool reports the install hint instead of falling back to one. Details and the alternatives considered are in ADR-401.

What to do: upgrade to 3.46.1. Installing agent-browser globally (npm i -g agent-browser) also avoids the fallback path on older versions.

The same change was audited across the other places that set shell on Windows (init, eject, agentbbs); none receives tool-supplied input.

Verification

A regression test drives the browser tools with shell metacharacters under both a Windows and a Linux platform and asserts each value reaches the process as a single literal argument. It fails on the previous code, and a static guard fails if a shell option is reintroduced.

Full details: #3451.

Full write-up (review method, validation, artifact integrities, what was held and why): https://gist.github.com/ruvnet/d7c5a6f1c3616dbbc6db91fdafb1db32