[BUG] # Bug report: Claude in Chrome via Cowork — all navigations instantly denied, no permission prompt ever renders

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?

Summary

From Claude Desktop (Cowork mode), every navigate call through the Claude in Chrome MCP returns Permission denied by user instantly, on all domains tested. No permission prompt ever renders — not in Chrome, not in the extension side panel, not in the desktop app. Read-tier operations work (tabs_context_mcp, tabs_create_mcp, list_connected_browsers all succeed; tab groups are created in Chrome).

Environment

• macOS (restarted during troubleshooting)
• Chrome (restarted; also tested in a fresh window with all other tabs closed)
• Claude in Chrome extension v1.0.75 (Beta), enabled, pinned
• Claude Desktop / Cowork mode, same Anthropic account in app and extension (verified)
• Date: 2026-06-12, afternoon CT

Settings verified correct before reporting

• Extension site access: On all sites (chrome://extensions → Claude → Details)
• claude.ai/settings/browser-extension: Default for all sites = Allow extension, Blocked sites list empty
• Extension signed in to the same account as the desktop app (verified on the extension options page)
• Extension options → Permissions → "Your approved sites": empty ("No sites have been approved yet") — and there is no way to add sites manually
• Chrome site-details for the extension (chrome://settings/content/siteDetails?site=chrome-extension://...): JavaScript/notifications/popups all allowed

Repro steps

1. In Cowork, call tabs_context_mcp {createIfEmpty: true} → succeeds, tab group + tab created in Chrome.
2. Call navigate {url: "https://jobs.ashbyhq.com/teamworks", tabId: <new tab>} → instant Permission denied by user. No prompt appears anywhere. The denial is immediate (no timeout window).

What was tried, in order (denial persisted after every step)

1. Changed claude.ai/settings/browser-extension "Default for all sites" from default to Allow extension → retried → denied
2. Created a brand-new tab in the MCP group → denied
3. Toggled the extension off/on in chrome://extensions → reconnected (tabs_context returned a fresh group) → denied
4. Quit and restarted Chrome entirely → denied
5. Full computer restart (restarts the Claude desktop app too), fresh Chrome window → denied

Expected

Either the navigation proceeds (default = Allow extension is set), or a permission prompt renders somewhere the user can act on it.

Actual

Instant Permission denied by user on every navigate, on every domain tested (jobs.ashbyhq.com tested repeatedly), with no prompt ever rendered. Matches the pattern in issue #49979 ("no approval popup renders") — including that the account-level Allow-extension setting is not honored by the Cowork-side check.

Impact

Cowork's browser automation is completely unusable for this account/machine: no live page verification, no form assistance, no JS-rendered site access. The user's workflow (job application pipeline) specifically depends on verifying JS-rendered job boards (amazon.jobs, Ashby, Workday) that the non-browser fetch tools cannot read.

Decisive isolation test (2026-06-12 evening)

The extension side panel works perfectly on the same machine/account/site: user opened the side panel on jobs.ashbyhq.com, asked Claude (Sonnet 4.6, "Ask before acting" mode) to inspect the Go-To-Market section, and it navigated and answered correctly ("Claude is active in this tab group" banner shown). Immediately afterward, a Cowork-path navigate to the SAME domain returned instant Permission denied by user. Same browser, same extension, same account, same minute. The defect is isolated to the Cowork/desktop → extension permission path. Side-panel usage did NOT populate "Your approved sites," so it cannot be used as a workaround to unblock Cowork.

Note

Side panel exhibited slow connection ("spinning" before connecting) on first open after restart — secondary issue, possibly unrelated.

What Should Happen?

Expected

Either the navigation proceeds (default = Allow extension is set), or a permission prompt renders somewhere the user can act on it.

Actual

Instant Permission denied by user on every navigate, on every domain tested (jobs.ashbyhq.com tested repeatedly), with no prompt ever rendered. Matches the pattern in issue #49979 ("no approval popup renders") — including that the account-level Allow-extension setting is not honored by the Cowork-side check.

Error Messages/Logs

## Note
Side panel exhibited slow connection ("spinning" before connecting) on first open after restart — secondary issue, possibly unrelated.

Steps to Reproduce

Repro steps

1. In Cowork, call tabs_context_mcp {createIfEmpty: true} → succeeds, tab group + tab created in Chrome.
2. Call navigate {url: "https://jobs.ashbyhq.com/teamworks", tabId: <new tab>} → instant Permission denied by user. No prompt appears anywhere. The denial is immediate (no timeout window).

What was tried, in order (denial persisted after every step)

1. Changed claude.ai/settings/browser-extension "Default for all sites" from default to Allow extension → retried → denied
2. Created a brand-new tab in the MCP group → denied
3. Toggled the extension off/on in chrome://extensions → reconnected (tabs_context returned a fresh group) → denied
4. Quit and restarted Chrome entirely → denied
5. Full computer restart (restarts the Claude desktop app too), fresh Chrome window → denied

Claude Model

Other

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude 1.12603.1 (3df4fd) 2026-06-11T16:57:36.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_