[BUG] Windows desktop: Claude_Browser MCP server registers zero tools since ~v2.1.229 (worked through v2.1.227)
Summary
On the Windows desktop app, the desktop-internal Claude_Browser MCP server (the one backing the Code tab's Browser pane) registers zero tools into sessions. None of mcp__Claude_Browser__* are exposed — not as loaded tools, not in the deferred-tool list.
This is a regression. The same server worked normally on the same machine, in the same project, through v2.1.227, and has produced zero tool calls in every session since v2.1.229.
Other desktop-native MCP servers in the same session are unaffected: computer-use, scheduled-tasks, ccd_session_mgmt, ccd_directory, and claude-in-chrome all register normally. It is specifically Claude_Browser that is missing, which distinguishes this from #87098 (where no desktop-native servers load in sdk-cli sessions).
Environment
- Claude Code v2.1.258 (read from the session transcript's
versionfield) - Claude desktop app, Code tab, native local session (not
sdk-cli, not SSH/WSL) - Windows 11 Home 10.0.26200
- Project: a local Next.js site repo, running in a git worktree
Expected
mcp__Claude_Browser__navigate, __preview_start, __preview_list, __computer, __read_page, __get_page_text, __find, __form_input, __javascript_tool, __read_console_messages, __read_network_requests, __tabs_*, __resize_window, __preview_stop, __preview_logs are available to the session, as they were on v2.1.227.
Actual
Probe 1 — direct select by name:
Query: select:mcp__Claude_Browser__navigate,mcp__Claude_Browser__preview_start,mcp__Claude_Browser__computer
Response, verbatim:
No matching deferred tools found
Probe 2 — keyword search (browser pane preview navigate screenshot, max_results 15):
Returns 15 tools, all from other servers — mcp__claude-in-chrome__* (navigate, browser_batch, computer, find, read_console_messages, resize_window, tabs_context_mcp, tabs_create_mcp, upload_image, gif_creator, select_browser, switch_browser, list_connected_browsers), mcp__computer-use__computer_batch, plus DesignSync and WebFetch.
Zero mcp__Claude_Browser__* entries. The session-start deferred-tool list likewise contains none.
Evidence that this is a version regression, not a config change
I scanned all ~305 local session transcripts under ~/.claude/projects/ and counted real tool_use invocations of mcp__Claude_Browser__*:
| Version range | Claude_Browser tool calls |
|---|---|
| v2.1.202 → v2.1.227 | 3,399 (last call 2026-08-12, on v2.1.227) |
| v2.1.229 → v2.1.258 | 0, across ~1,290 sessions |
Restricting to web/frontend projects, where the Browser pane is actually useful:
- On v2.1.219: 66 of 351 such sessions used the browser tools (~19%)
- After v2.1.229: 0 of 270
The specific project I probed above is one where it demonstrably worked — 21 sessions used these tools, several with 20–35 calls each, most recently 2026-08-12 on v2.1.227. Nothing about that project's MCP configuration changed in between.
So the drop is not "users stopped reaching for it": the capability probe above shows the tools are not registered, in a project with a documented working baseline.
Steps to reproduce
- Windows desktop app, Code tab, open a local project as a normal (non-
sdk-cli) session on v2.1.258. - Ask the session to search its deferred tools for
mcp__Claude_Browser__navigate. - Observe
No matching deferred tools found, whilemcp__claude-in-chrome__*andmcp__computer-use__*resolve fine.
Possibly related
There is a cluster of open Windows reports where the Browser pane crashes the GPU process or the whole app: #91290, #90892, #90418, #87013, #81749. My exact OS build (10.0.26200) appears in one of them.
I have not established a causal link — I don't know whether the server was deliberately gated off on Windows in response to those crashes, or whether it regressed silently. If it was an intentional mitigation, saying so in the release notes would help; right now the tools simply vanish with no message, and docs/project instructions that reference preview_* become silently wrong.
Impact
Any project guidance that says "use the preview_* tools to verify changes" is dead on current versions. The workarounds (playwright-cli, a Playwright test suite, or the claude-in-chrome extension) all work but are heavier, and claude-in-chrome drives the user's real browser rather than an embedded pane.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗