Summary
On Windows 11 with Chrome 151, the gsd-browser daemon dies during startup. The Rust CDP message deserializer rejects messages emitted by this Chrome build, so every MCP browser_* tool and the gsd-browser CLI (navigate / set-viewport / etc.) hangs or crashes. There is no working session.
Environment
@opengsd/gsd-browser: 0.2.2 (latest published)- Chrome: 151.0.7922.170 (
C:\Program Files\Google\Chrome\Application\chrome.exe)
- OS: Windows 11 Home 26200
- Node: >=16
Symptoms / logs
Daemon startup logs the following, then exits:
WARN WS Invalid message: data did not match any variant of untagged enum Message
daemon exited during startup with status exit code: 1
The first line points at the untagged-enum CDP Message deserializer failing to match a frame from Chrome 151. The daemon then terminates with exit code 1 before it is ready, so no browser session is ever established.
Additional observation (may be a second, separable issue)
Loopback fetches from the controlled browser are refused with:
localNetworkAccessRequestPolicy: PermissionBlock
Chrome 151 enforces the Local Network Access permission gate; automating http://localhost:* targets requires the LocalNetworkAccess check to be disabled on launch. Worth surfacing in docs even independent of the deserializer crash.
Impact
Complete loss of the tool surface on this machine — no MCP browser tools and no CLI navigation are usable against Chrome 151.
Workaround in use
Bypassing the daemon entirely: launching headless Chrome with --remote-debugging-port=9222 (and LocalNetworkAccess checks disabled) and driving it over a raw CDP WebSocket from a small Node script. Functional, but a parallel path rather than a fix.
Likely root cause
The untagged Message enum in the daemon's CDP deserializer doesn't cover a message shape/variant introduced (or changed) in Chrome 151's protocol output. A tolerant/#[serde(other)]-style fallback, or updating the protocol schema to Chrome 151, would likely resolve it.
Summary
On Windows 11 with Chrome 151, the gsd-browser daemon dies during startup. The Rust CDP message deserializer rejects messages emitted by this Chrome build, so every MCP
browser_*tool and thegsd-browserCLI (navigate / set-viewport / etc.) hangs or crashes. There is no working session.Environment
@opengsd/gsd-browser: 0.2.2 (latest published)C:\Program Files\Google\Chrome\Application\chrome.exe)Symptoms / logs
Daemon startup logs the following, then exits:
The first line points at the untagged-enum CDP
Messagedeserializer failing to match a frame from Chrome 151. The daemon then terminates with exit code 1 before it is ready, so no browser session is ever established.Additional observation (may be a second, separable issue)
Loopback fetches from the controlled browser are refused with:
Chrome 151 enforces the Local Network Access permission gate; automating
http://localhost:*targets requires the LocalNetworkAccess check to be disabled on launch. Worth surfacing in docs even independent of the deserializer crash.Impact
Complete loss of the tool surface on this machine — no MCP browser tools and no CLI navigation are usable against Chrome 151.
Workaround in use
Bypassing the daemon entirely: launching headless Chrome with
--remote-debugging-port=9222(and LocalNetworkAccess checks disabled) and driving it over a raw CDP WebSocket from a small Node script. Functional, but a parallel path rather than a fix.Likely root cause
The untagged
Messageenum in the daemon's CDP deserializer doesn't cover a message shape/variant introduced (or changed) in Chrome 151's protocol output. A tolerant/#[serde(other)]-style fallback, or updating the protocol schema to Chrome 151, would likely resolve it.