[BUG] Windows desktop: Claude_Browser MCP server registers zero tools since ~v2.1.229 (worked through v2.1.227)

Status Open
Maintainer reply None cached
Activity 2 comments · opened Sep 4, 2026

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 version field)
  • 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

  1. Windows desktop app, Code tab, open a local project as a normal (non-sdk-cli) session on v2.1.258.
  2. Ask the session to search its deferred tools for mcp__Claude_Browser__navigate.
  3. Observe No matching deferred tools found, while mcp__claude-in-chrome__* and mcp__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.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗