[BUG]Cowork agentic capability collapse — per-action approval dispatcher broken on all browser MCP tools

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Cowork mode: every Claude in Chrome MCP tool (navigate, read_page, form_input, computer, javascript_tool) returns "Permission denied by user" without ever showing an approval prompt to the user. The Native Messaging bridge is alive — tabs_context_mcp works — but the per-action approval dispatcher fails silently. This has collapsed a headline Cowork capability for weeks. Multiple identical reports exist: #27073, #43255, #48806, #30356.

What Should Happen?

navigate / read_page / form_input / computer should either succeed after a single user approval, or show an approval prompt. Currently they silently fail with a misleading "Permission denied by user" the user never issued.

Error Messages/Logs

Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist. at mcpPermissions-D7Rkh1yL.js:1

Steps to Reproduce

1. Install Claude in Chrome extension, accept initial permissions. 2. Open Claude Desktop in Cowork mode. 3. From Cowork, invoke any browser action (e.g., navigate to example.com). 4. Observe: no approval UI appears; MCP tool returns "Permission denied by user". 5. Service worker DevTools shows recurring "Receiving end does not exist" error.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

unknown

Claude Code Version

1.3109.0

Platform

Other

Operating System

macOS

Terminal/Shell

Other

Additional Information

What we need

In priority order:

1. Fix the dispatcher error mapping. A "receiver not found" condition is not a user denial. Minimum viable fix: stop returning Permission denied by user when the receiver is missing; return a distinct error and surface it in Claude Desktop itself.

1. Route per-action approvals through a persistent channel. The service worker and/or Native Messaging host to Claude Desktop are always alive. Use them. Don't depend on a content script / side panel that may not exist in a Cowork session.

1. Surface the approval UI in Claude Desktop when the browser call originates from Cowork, not in the Chrome side panel (which the user is often not looking at).

1. Expose "Allow all browser actions" to Pro/Max users as a temporary self-serve workaround while the dispatcher fix ships.

1. Public status post. This is multi-week-old, multi-reporter breakage of a headline capability. A GitHub or changelog acknowledgment would let users stop hunting for configuration errors that aren't theirs.

Personal note

I bought into Cowork specifically because the browser was the glue between the pieces that otherwise don't talk to each other. Losing that glue silently — with a "Permission denied by user" error that blames me for a denial I never issued — is the worst failure mode possible: it trains users to believe the tool is working as designed and that they're misconfiguring it, while in reality the feature is broken upstream. Please prioritize this.

— Tei