[BUG] Claude in Chrome v1.0.69: permission_required returned for all MCP navigations to a domain; approval popup never 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

Every MCP-initiated navigation via mcp__Claude_in_Chrome__navigate to a previously-unapproved domain returns the error string permission_required: <hostname> and is rejected. The expected approval popup ("Always allow actions on this site" or similar) never renders, so there is no user-facing way to populate the extension's internal allowlist.

This appears to be the same regression class as #27073 and #49999.

Environment

• Claude in Chrome extension version: 1.0.69
• Extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn
• Chrome browser, Windows
• Claude Code (CLI) on Linux (WSL/remote dev container)
• Domain attempted: http://dockerdev.jeromes.com:8106 (an internal HTTP-only dev host)

What Should Happen?

Expected behavior

Per the Claude in Chrome Permissions Guide: the first MCP-initiated action against a new domain should render an "Always allow actions on this site" approval prompt. After approval, subsequent MCP calls to that domain should succeed.

Actual behavior

Approval prompt never renders. No state mutation possible from any UI surface I can find. MCP gate stays closed permanently for that domain.

Impact

This blocks all browser-based smoke testing for our team's pre-cutover release rehearsal (production migration scheduled for 2026-05-04). We have a documented test plan that cannot be exercised.

Workarounds in flight

• Manual smoke testing in a non-MCP-controlled tab (works, but loses the auditable scripted-flow benefit).
• Looking for a teammate who hasn't auto-updated to v1.0.69 to sideload an older .crx.

Anything else you'd like reproduced or any flag I can set on the extension to surface more diagnostic output?

<img width="1311" height="928" alt="Image" src="https://github.com/user-attachments/assets/630edd01-4057-425d-b2bd-5a68281a86b2" />

Error Messages/Logs

"PermissionManager retry loop fires chrome.debugger.attach without tracking in-flight attempts → continuous 'Another debugger is already attached' rejections, masked as permission_required to MCP callers" is your one-line diagnosis.

Steps to Reproduce

Reproduction

1. Fresh Claude Code session, MCP Claude in Chrome configured.
2. Issue any of: mcp__Claude_in_Chrome__navigate, browser_batch with a navigate action, etc., targeting a host the extension has never seen.
3. Observe: tool returns permission_required: dockerdev.jeromes.com. No popup. No badge on the toolbar icon. No notification.

What I tried (none of these unblocked the MCP gate)

• Chrome's per-site "Site access" dropdown set successively to "On click" → "On specific sites" with http://dockerdev.jeromes.com:8106/* → "On all sites".
• Toggled "Allow access to file URLs", "Allow in incognito", "Collect errors" all on.
• Chrome chrome://settings/content for the host: enabled popups, redirects, JavaScript, insecure content.
• Full Chrome restart.
• Extension uninstall + reinstall.
• Manual user-initiated navigation in the MCP-controlled tab via the address bar — no extension popup or banner appears during the load.
• Inspected the extension service-worker view (chrome://extensions/?id=fcoeoabgfenejglbffodgkkbkcdhcgfn → "Inspect views: service worker"); no obvious approval UI surfaces.

The fact that permission_required is returned identically regardless of Chrome's Site Access setting suggests the gate lives entirely inside the extension service worker and is decoupled from Chrome's permission model.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Code for Windows 1.4758.0 (fb266c) 2026-04-24T20:22:30.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_