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

Status Closed — not planned

Reported on v2.1.78

Maintainer reply None cached

Activity 15 comments · opened Mar 25, 2026 · closed Jun 12, 2026

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

Have Claude Desktop on Windows auto-update to 1.1.8359+ (currently 1.1.8629)
Ensure Claude in Chrome extension is connected to Edge
Open a Cowork session
Attempt to use any skill that requires browser automation
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:

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.
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)

View original on GitHub ↗

14 Comments

michael-head-leeco · 5 months ago

Additional context: Multi-machine setup

I have Claude Desktop installed on 3 machines under the same Anthropic account:

2 Windows PCs that share a OneDrive (Lee Company tenant)
1 Windows VM on a separate network

All 3 are logged into the same account. The Claude Desktop config lives in the MSIX-sandboxed path (AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\) which is local per machine and NOT synced by OneDrive. However, all 3 machines share the same Chrome extension bridge endpoint (wss://bridge.claudeusercontent.com/chrome/<account-id>), which could mean they compete for the pairing.

That said, the toolCount drop (19 → 3) is strictly version-correlated — every session on 1.1.6679 had 19 tools, every session on 1.1.8359+ has 3 — so this appears to be a regression rather than an environment conflict. Mentioning this in case it's relevant to reproducing or debugging.

michael-head-leeco · 5 months ago

Cross-reference: This appears to be the same underlying issue as #27492

Issue #27492 ("Claude cowork MCP Issue continues") has 20 comments spanning Feb–March 2026 describing the same pattern:

MCP servers (mcp-registry, Claude in Chrome) fail to connect after Desktop auto-update
Browser automation tools drop from full set to minimal (tab close, file upload only)
Confirmed on both macOS and Windows
@gskornowicz confirms still broken on Windows 11 with version 1.1.8359 — same version/symptom as this issue
@eyesWIDEopen12392 reports "Cowork only shows tab closing and file upload tools — no Chrome browsing tools" — identical to our toolCount drop (19 → 3)

No official Anthropic response on either thread. Attempting the disconnect/reconnect workaround documented in #27492.

michael-head-leeco · 5 months ago

Update: Disconnect/reconnect workaround from #27492 does NOT fix this

Attempted the full disconnect/reconnect cycle documented in #27492:

Disabled Claude in Chrome connector in Desktop settings
Disabled Claude extension in Edge
Full computer restart
Re-enabled connector in Desktop first, then extension in Edge (order matters per workaround)
Started a Cowork task requiring browser access

Result: Still only 3 tools registered (switch_browser, tabs_close_mcp, file_upload). The full browser automation tools (navigate, click, type, screenshot, tabs_create_mcp, etc.) are still missing. Cowork used web search as a fallback instead of browser tools for a "go to weather.com" task.

The config file now shows "chromeExtensionEnabled": true — the pairing and bridge connection work, but the computer-use MCP server is simply not being spawned by the Desktop app. This is a different root cause than the stale bridge token issue in #27492.

Desktop version: 1.1.8359+
Extension version: 1.0.64
OS: Windows 11 Enterprise

dfinlen · 5 months ago

My scheduled tasks in Claude Cowork fail, and it pops up an error saying "unable to communicate with Chrome".
I tried

uninstalling and re-installing did nothing
ensured both accounts in Chrome and cowork are the same
reproducible despite the transient connection warning

Chrome doesn't open, even when I try to run it manually. I have to have chrome running and it will work.. So maybe not the same problem. I'm going to try to reinstall everything (browser extension and Claude cowork).

More details

Request

{
createIfEmpty: true
}
Response

⚠️ Claude in Chrome is not connected

The Chrome extension isn't reachable right now. This is often transient — the connection usually recovers automatically within a few seconds.

Retry the browser tool in a moment. If it keeps failing, ask the user to check that Chrome is open with the extension signed in, or use alternative approaches (web search, ask the user to do it manually).

berkjb · 5 months ago

Confirming this on macOS - broken for ~6 weeks, same root cause
Adding a macOS confirmation here. I've been troubleshooting this for roughly six weeks with no resolution. My colleagues on the same Tripkicks org account do not have this issue, which suggests something account- or device-specific is compounding the Desktop regression.
Environment: macOS, Claude Desktop 1.1.8359+, Cowork mode, Chrome extension ID fcoeoabgfenejglbffodgkkbkcdhcgfn
What I see: Claude in Chrome registers as installed but only exposes 3 tools (switch_browser, file_upload, tabs_close_mcp) instead of the full set. mcp-info.json shows "activeServers": [] and "configurations": {} even when the extension is paired.
Log evidence confirming the root cause: In the Cowork session spawn args, computer-use appears in --allowedTools but is completely absent from --mcp-config. This matches exactly what's described in this issue.
Additional finding: I was seeing selected=none on all bridge disconnects alongside an OAuth 500 error from the extension. Clearing claude.ai cookies (not just cache) in Chrome changed the logs to show "Paired with Chrome extension," but the tool set still only registered 3 tools - so the OAuth issue is a separate layer on top of this Desktop regression.
Workaround: Browser automation via the CLI (claude terminal) works fine because it uses the native host socket directly, bypassing the bridge entirely. But this is not a solution for Cowork users.

michael-head-leeco · 5 months ago

Thanks @berkjb — your log evidence is the clearest confirmation yet that this is the same root cause cross-platform. The computer-use in --allowedTools but absent from --mcp-config pattern matches exactly what we see on Windows.

Your finding that colleagues on the same org account don't have the issue is interesting. On our end, we have 3 machines on the same Anthropic account — would be worth knowing if the issue follows specific devices or appears after a specific update path (e.g., the rapid triple-update from 1.1.6679 → 1.1.8359 we experienced).

mattberns · 4 months ago

Our organization is experiencing the same issue as precisely described in the original post. Very frustrating.

berkjb · 4 months ago

It looks like there might be a new User Setting --> in "Desktop App --> Extensions, where you could install and "Control Chrome". This seems to have fixed it for me!

mattberns · 4 months ago

It looks like there might be a new User Setting --> in "Desktop App --> Extensions, where you could install and "Control Chrome". This seems to have fixed it for me!

Says MacOS only. Yet I've actually controlled Chrome via my Windows PC before...

eyesWIDEopen12392 · 4 months ago

Don't really understand why their support is completely ghosting me (us) on this issue. Hard to continue paying Anthropic for a license if this is the modus operandi

michael-bud · 4 months ago

Also having same issue on OSX. Seems like lots of reports. Fairly major feature to remain broken for several weeks.

eyesWIDEopen12392 · 4 months ago

Debugging a persistent Claude Desktop issue on Windows 11 Pro that has affected my workflow for weeks. Posting in case others are seeing the same thing or in case it reaches someone at Anthropic who can route it.

Symptom: "Failed to start Claude's workspace. VM service not running."

Root cause (isolated tonight after extensive diagnosis): Claude Desktop's MSIX package ships a Windows service called CoworkVMService, but the service's ACL does not grant start/stop rights to the logged-in user. Result: the app cannot start its own service when running under a standard non-elevated user token. It can only start the service if the app itself is "Run as Administrator."

Evidence:

Service starts cleanly when invoked from an elevated PowerShell (Start-Service CoworkVMService)
Cowork functions end-to-end when Claude Desktop is launched "as Administrator"
Same machine, same software, same Hyper-V config; only variable is the privilege context
Reinstalling does not resolve (reinstalls ship the same ACL)
Persists across app versions 1.1617 through 1.3109

This likely affects users on properly-configured Windows 11 Pro machines with UAC enabled. I suspect internal testing runs with elevated tokens, which is why it hasn't been caught.

Filed as a new support ticket with complete logs and reproduction steps.

fabianoahlert · 3 months ago

Subject: Claude in Chrome not connecting to Cowork on Windows — VM-to-host bridge broken

Message:
Claude in Chrome is completely non-functional in Cowork on Windows. I performed a detailed
diagnostic and identified the exact point of failure.

Environment:

Claude Desktop: version 1.7.x, Windows, MSIX installation (Windows Store)
Claude in Chrome extension: version 1.0.70
Chrome: extension active, ID fcoeoabgfenejglbffodgkkbkcdhcgfn

Diagnostic performed:
All components on the Windows side are working correctly:

✅ Native messaging host registry entry exists and points to the correct path
✅ The chrome-native-host.exe executable exists at the correct path
✅ The installed extension ID (fcoeoabgfenejglbffodgkkbkcdhcgfn) is in the manifest's
allowed_origins list
✅ The named pipe \\.\pipe\claude-mcp-browser-bridge-admin exists on Windows
✅ The chrome-native-host.exe process is running (Chrome launched it correctly)

Identified point of failure:
The Unix socket /tmp/claude-mcp-browser-bridge-admin does NOT exist inside the Cowork
Linux VM. The VM-to-host bridge is not exposing the Windows named pipe into the Cowork
execution environment. This prevents any MCP call to Chrome from working, even with all
Windows-side components functioning correctly.

Error received: Claude in Chrome is not connected on all MCP calls, including
tabs_context_mcp with createIfEmpty: true.

Related GitHub issue: #38783 describes the same problem following Claude Desktop updates
in March 2026.

The problem persists after: reinstalling Claude Desktop (updated to version 1.7.x),
restarting the computer, and re-enabling all relevant permissions.

github-actions[bot] · 2 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Showing cached comments. Read the full discussion on GitHub ↗

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

Description

Environment

Evidence from logs

Claude in Chrome toolCount dropped from 19 to 3

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

Previously working (pre-update)

Registry and native messaging verified correct

Version progression on March 23

Steps to reproduce

What I've tried (all unsuccessful)

Expected behavior

Actual behavior

Additional symptom: Cowork artifact downloads fail

Root cause analysis

Connection between the two issues

Related issues

14 Comments

Additional context: Multi-machine setup

Cross-reference: This appears to be the same underlying issue as #27492

Update: Disconnect/reconnect workaround from #27492 does NOT fix this

Related Claude Code issues

Browse by topic