[BUG] Windows: Cowork browser automation tools missing after Claude Desktop update — computer-use tools never register

Description

After Claude Desktop auto-updated through multiple versions on March 23, 2026 (1.1.6679 → 1.1.7714 → 1.1.8308 → 1.1.8359 → 1.1.8629), all browser automation tools are missing from Cowork sessions. The Claude in Chrome MCP server connects successfully and authenticates, but only exposes 3 basic tools (tabs_close_mcp, file_upload, switch_browser). The full computer-use browsing tools (navigate, read_page, click, type/form_input, screenshot, find, javascript_tool, tabs_context_mcp) never register.

Skills that depend on browser automation (which worked prior to the update) now fail immediately with:

Unfortunately, I'm missing the core automation tools that this skill requires: navigate, read_page, click, type / form_input, screenshot, find, javascript_tool, tabs_context_mcp

Environment

• OS: Windows 11 Enterprise 10.0.26200
• Claude Desktop: 1.1.8629 (MSIX install via Windows Store)
• Claude Code (CCD): 2.1.78
• Browser: Microsoft Edge (paired via Claude in Chrome extension)
• Chrome Canary: Not installed
• Plan: Max (Opus 4.6)

Evidence from logs

Claude in Chrome toolCount dropped from 19 to 3

Pre-update (March 13, version 1.1.6679) — main.log shows:

{
  "name": "Claude in Chrome",
  "status": "connected",
  "scope": "dynamic",
  "toolCount": 19
}

Post-update (March 25, version 1.1.8629) — same log shows:

{
  "name": "Claude in Chrome",
  "status": "connected",
  "scope": "dynamic",
  "toolCount": 3
}

The extension connects and authenticates fine. 16 tools simply vanished.

Cowork VM spawns with computer-use in allowedTools but no computer-use MCP server configured

From cowork_vm_node.log, sessions are spawned with:

--allowedTools ...mcp__Claude_in_Chrome,mcp__computer-use,...

But the --mcp-config server list does NOT include a computer-use server:

{"mcpServers":{
  "ab4ab624-...":{"type":"sdk","name":"ab4ab624-..."},
  "4ae5bfe1-...":{"type":"sdk","name":"4ae5bfe1-..."},
  "c1fc4002-...":{"type":"sdk","name":"c1fc4002-..."},
  "Claude in Chrome":{"type":"sdk","name":"Claude in Chrome"},
  "mcp-registry":{"type":"sdk","name":"mcp-registry"},
  "plugins":{"type":"sdk","name":"plugins"},
  "scheduled-tasks":{"type":"sdk","name":"scheduled-tasks"},
  "cowork":{"type":"sdk","name":"cowork"},
  "session_info":{"type":"sdk","name":"session_info"}
}}

No computer-use entry. The Desktop app is supposed to provide these tools via the VM-to-host bridge, but they never materialize.

Previously working (pre-update)

On March 13-20 (version 1.1.6679), the same setup successfully used browser tools:

[Claude in Chrome] Error calling tool: [Claude in Chrome] Tool call timed out: computer
[Claude in Chrome] Tool call error: javascript_tool (9496d938) after 1447ms
[Claude in Chrome] Tool call timed out: get_page_text

These show the tools existed and were callable (timeouts were unrelated transient issues). After the update, these tools simply don't exist at all.

Registry and native messaging verified correct

Native messaging host registry entries are correctly configured for both Chrome and Edge:

HKCU\SOFTWARE\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension
→ C:\Users\...\Claude\ChromeNativeHost\com.anthropic.claude_browser_extension.json

HKCU\SOFTWARE\Microsoft\Edge\NativeMessagingHosts\com.anthropic.claude_browser_extension
→ C:\Users\...\Claude\ChromeNativeHost\com.anthropic.claude_browser_extension.json

The manifest and chrome-native-host.exe are present and valid.

Version progression on March 23

16067: Starting app { appVersion: '1.1.7714' } // 19:16:10
16087: Starting app { appVersion: '1.1.8308' } // 19:17:12
16213: Starting app { appVersion: '1.1.8359' } // 19:19:40

Three updates within 4 minutes. Browser tools were missing from the first post-update session onward. App has since auto-updated further to 1.1.8629.

Steps to reproduce

1. Have Claude Desktop on Windows auto-update to 1.1.8359+ (currently 1.1.8629)
2. Ensure Claude in Chrome extension is connected to Edge
3. Open a Cowork session
4. Attempt to use any skill that requires browser automation
5. Observe that computer-use tools are not available

What I've tried (all unsuccessful)

• Restarted Claude Desktop completely (multiple times)
• Restarted Edge completely
• Disconnected and reconnected the Chrome extension
• Forced extension update check in edge://extensions (Developer Mode → Update)
• Reinstalled the Claude in Chrome extension
• Verified extension site permissions (All sites)
• Verified native messaging host registry entries exist and are correct for both Edge and Chrome
• Started fresh Cowork sessions
• Cleared and restarted multiple times

Expected behavior

Cowork sessions should have access to the full set of browser automation tools (navigate, read_page, click, type, screenshot, find, javascript_tool, tabs_context_mcp) as they did prior to the update. Claude in Chrome should report toolCount: 19, not toolCount: 3.

Actual behavior

Only 3 basic Claude in Chrome tools are available (tabs_close_mcp, file_upload, switch_browser). The computer-use browser automation tools are completely absent. The computer-use MCP server is referenced in --allowedTools but never configured in --mcp-config.

Additional symptom: Cowork artifact downloads fail

In the same build, attempting to open or download Cowork artifacts (e.g., "Open in Notepad") produces:

The system cannot find the path specified.

Root cause analysis

Cowork sessions run inside a sandboxed VM with Unix-style paths (e.g., cwd=/sessions/modest-exciting-keller). From cowork_vm_node.log:

[Spawn:create] id=580614be... name=modest-exciting-keller
cmd=/usr/local/bin/claude
cwd=/sessions/modest-exciting-keller

When a user clicks "Open in Notepad," the Desktop app must map the VM path to a real Windows host path. After the update, this mapping fails — the path passed to Windows doesn't resolve to an actual file on disk.

Connection between the two issues

Both symptoms point to the same root cause: the VM-to-host bridge is broken in recent builds on Windows. The bridge is responsible for:

1. Injecting computer-use tools into Cowork sessions — The --allowedTools flag includes mcp__computer-use, but it's absent from the --mcp-config server list. The Desktop app is supposed to provide these tools via the bridge, but they never materialize.
2. Mapping VM file paths to host filesystem paths — Artifacts created inside the VM at /sessions/<name>/... need to be translated to Windows paths for external apps like Notepad. This translation is failing.

Both capabilities worked on version 1.1.6679 and broke after the update to 1.1.8359+. The Chrome extension itself connects fine (3 basic plumbing tools work); the issue is the layer above it that the Desktop app is supposed to provide.

Related issues

• #27492 — Similar symptom on macOS (MCP server connection failures after update), but different root cause (servers fail to connect entirely; in this case servers connect but tools are missing)
• #38088 — computer-use parameter type errors on 1.1.8359 (macOS), suggests the computer-use subsystem has issues in this build
• #25663 — Cowork workspace bricked after Chrome automation on Windows (different failure mode)