Claude in Chrome v1.0.70: `permission_required` regression continues from #53630 — approval popup never renders, all MCP navigations blocked

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?

GitHub issue draft — paste into anthropics/claude-code

Title

[BUG] Claude in Chrome v1.0.70: `permission_required` regression continues from #53630 — approval popup never renders, all MCP navigations blocked

Body

---

Summary

Claude in Chrome v1.0.70 ships with the same approval-popup regression that #53630 documented and closed for v1.0.69. Every mcp__Claude_in_Chrome__navigate call returns permission_required: <host> regardless of the URL, and the "Always allow on this site" popup that is supposed to populate the in-extension allowlist (Settings → Permissions → Your approved sites) never renders. Because the only documented way to add a site to that allowlist is the popup, and the Permissions page itself has no "Add site" button (#21723), there is no user-facing path to unblock MCP-driven browser automation.

This is a continuation of the same regression family as #53630 (v1.0.69) and #50606 (v1.0.66+). Yesterday (2026-05-06) the same workstation, account, and extension ID worked end-to-end on a pre-1.0.66 build; the extension auto-updated overnight and the regression returned today (2026-05-07).

Affected versions

| Issue | Version | Symptom variant |
|---|---|---|
| #50606 | v1.0.66+ | Navigation to this domain is not allowed |
| #53630 (Closed) | v1.0.69 | permission_required: <host> |
| This issue | v1.0.70 | permission_required: <host> |

Steps to reproduce

// 1. Sanity — these calls work, proving the connection layer is healthy
mcp__Claude_in_Chrome__list_connected_browsers          → ✅ returns Browser 1, deviceId, etc.
mcp__Claude_in_Chrome__select_browser({ deviceId })     → ✅ "Connected to browser Browser 1"
mcp__Claude_in_Chrome__tabs_context_mcp({ createIfEmpty: true })
                                                         → ✅ returns { tabId, url: "chrome://newtab/" }

// 2. The failing call — fails identically on every URL
mcp__Claude_in_Chrome__browser_batch({
  actions: [
    { name: "navigate",  input: { url: "https://example.com", tabId } },
    { name: "computer",  input: { action: "wait", duration: 2, tabId } },
    { name: "computer",  input: { action: "screenshot", tabId } }
  ]
})
→ Error: actions[0] (navigate) failed: permission_required: example.com (0 completed, 2 remaining)

Confirmed against:

• https://example.com — public, no redirect, no auth, no JS dialogs → fails
• https://google.com → fails
• https://maheslcm--crmfull.sandbox.my.site.com/... (Salesforce sandbox, the original target) → fails
• about:blank → separate error (Failed to navigate: Invalid URL: about:blank), not interesting

Expected behavior

Per the Claude in Chrome Permissions Guide:

1. First MCP-initiated navigation to a new domain triggers an in-extension approval popup ("Always allow Claude to act on this site?")
2. User clicks Always allow on this site
3. The host is added to Settings → Permissions → Your approved sites
4. Subsequent navigate / computer / find / read_page calls on that host succeed

This is what was happening on this workstation as recently as 2026-05-06 on an earlier (pre-1.0.66) extension version.

Actual behavior

1. First MCP-initiated navigate returns permission_required: <host> immediately, with no popup overlay rendered on the page, no popup in the Claude side panel (even when ⌘E was pressed before the call), and no Chrome notification
2. Settings → Permissions → "Your approved sites" stays at "No sites have been approved yet" — and there is no UI to add a site manually (#21723), so this state is permanently unreachable
3. Every subsequent navigate to any host returns the same error
4. All downstream tools (computer screenshot, find, read_page, browser_batch with multiple actions) are unusable because they require an active non-chrome://newtab/ tab, which navigate can no longer produce

Suspected root cause (per #53630)

Quoting #53630's root-cause comment:

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

The extension's Access the page debugger backend permission (visible at chrome://extensions for this extension ID) is consistent with chrome.debugger being the underlying mechanism. The race described would explain why the popup never settles to render. Closing #53630 against v1.0.69 either didn't fix this race in v1.0.70, or fixed one path but left another that surfaces identically to MCP callers.

Workarounds I attempted (none worked)

In a focused 30+ minute debug session today against example.com:

| # | Attempt | Result |
|---|---|---|
| 1 | Click "Always allow on this site" in extension popup | Popup never rendered, so this couldn't be done |
| 2 | Grant per-host on every URL in the redirect chain via Chrome puzzle icon → 3-dot menu → "On <host>" | Sets Chrome's Site Access; doesn't populate Claude's internal allowlist; navigate still fails |
| 3 | Set Chrome Site Access to "On all sites" | navigate still fails |
| 4 | Quit Chrome (⌘Q), reopen, fresh tab group | navigate still fails |
| 5 | select_browser with the deviceId to re-establish connection | Connected fine, navigate still fails |
| 6 | Uninstall the extension via chrome://extensions → reinstall fresh from Chrome Web Store | Web Store served the same v1.0.70 back; navigate still fails |
| 7 | Try https://example.com (public, no redirect, no auth) | Fails identically — rules out host-specific or redirect-chain causes |
| 8 | Open the Claude side panel (⌘E) before retrying, in case popup needed a UI surface | Still no popup; navigate still fails |
| 9 | Inspect Settings → Permissions for an "Add site" button | None exists (#21723) — list is read-only |
| 10 | Check Anthropic status page (status.claude.com) for an active Browser MCP incident | No incidents; Claude Code listed as Degraded but not in a way that matches this symptom |

What still works on the buggy version (proving the connection / transport layer is healthy):

• list_connected_browsers, select_browser, tabs_context_mcp, tabs_create_mcp
• mcp__salesforce-dx__* (entirely independent of Chrome MCP)

So the failure is isolated to the navigate-and-grant path inside the Claude in Chrome extension itself.

Environment

| Component | Value |
|---|---|
| Claude in Chrome extension | v1.0.70 (Beta) |
| Extension ID | fcoeoabgfenejglbffodgkkbkcdhcgfn |
| Source | Chrome Web Store (Site access shown as "On all sites") |
| Chrome | latest stable as of 2026-05-07 |
| Platform | macOS Darwin 25.5.0 |
| Caller | Claude Code CLI (Opus 4.7, 1M context) |
| Account (extension signed-in) | meetings@thekenverse.com |
| Account (Claude Code CLI runs as) | rajendra@thekenverse.com |
| Profile | Chrome profile managed by thekenverse.com (Google Workspace) — only Claude extension installed |

The two-account detail is potentially relevant: the extension is signed into a different Google Workspace identity than the Claude Code CLI driving the MCP calls. Both are on the same managed thekenverse.com profile. If the extension's permission flow does an account-equality check against the caller, this configuration would consistently fail.

Yesterday-worked-today-broken delta

| | 2026-05-06 (worked) | 2026-05-07 (broken) |
|---|---|---|
| Workstation | Same | Same |
| Account (extension) | meetings@thekenverse.com | meetings@thekenverse.com |
| Account (CLI) | rajendra@thekenverse.com | rajendra@thekenverse.com |
| Chrome | Same major version | Same |
| Extension | Pre-1.0.66 (auto-update hadn't fired) | v1.0.70 (auto-updated overnight) |
| Behavior | permission_required on first navigate → popup rendered → user clicked "Always allow" → subsequent calls succeeded | permission_required on every navigate → popup never renders → no path to recovery |

The only delta is the extension version. This is a regression, not a configuration issue.

Screenshots (available, can attach)

1. chrome://extensions/?id=fcoeoabgfenejglbffodgkkbkcdhcgfn showing Version 1.0.70, Site access "On all sites", and "Access the page debugger backend" permission
2. Extension Options → Permissions tab showing "Your approved sites: No sites have been approved yet" with no Add UI
3. Failed browser_batch invocation showing the exact permission_required: example.com (0 completed, 2 remaining) error
4. Chrome puzzle-icon → 3-dot menu showing "On example.com" radio selected (Chrome-side grant) coexisting with the failure (proving the two permission systems are decoupled)

Asks

1. Reopen #53630 or treat this as a follow-up issue — the regression persists in v1.0.70.
2. Confirm whether v1.0.70 carries the same PermissionManager / chrome.debugger.attach race, and whether a fix is queued for v1.0.71+.
3. Provide an interim path to populate "Your approved sites":

• An "Add site" button on the Permissions page (resolves #21723 too), or
• A documented sideloadable older .crx for users blocked on the regression, or
• A chrome.storage.local entry users can set via DevTools to bypass the popup.

1. If the popup mechanism is gated on a particular caller surface (extension side panel only, not Claude Code CLI), document that — the current Permissions Guide doesn't.

Related issues

• #53630 — v1.0.69 popup-render regression (Closed; this is a continuation)
• #50606 — v1.0.66+ "Navigation to this domain is not allowed" variant (same bug class)
• #21723 — Permissions page lacks "Add site" UI (forces users into the broken popup flow; if popup is broken, users have no recovery)
• #27073 — claude.ai-side variant of the same silent-fail pattern
• #49979 — Claude Desktop on Windows 11 variant
• #26779 — security issue: Chrome extension site permissions can be bypassed via direct LevelDB write (related to allowlist storage)

Impact

All MCP-driven UI testing is blocked on this account. The use case is visual UAT against a Salesforce LWR portal (Lightning community on a managed sandbox); the entire scripted-flow benefit of Browser MCP is lost. Manual user-driven screenshots remain as the only fallback. Salesforce DX MCP is unaffected and continues to work normally.

What Should Happen?

Per the Claude in Chrome Permissions Guide, the first MCP-initiated mcp__Claude_in_Chrome__navigate call against a previously-unapproved domain should render an in-extension "Always allow Claude to act on this site?" approval popup. After the user clicks "Always allow on this site", the host should be added to Settings → Permissions → "Your approved sites", and subsequent MCP calls (navigate, computer screenshot, find, read_page, browser_batch) on that host should succeed.

This was the working behaviour on this same workstation on 2026-05-06 with a pre-1.0.66 version of the extension.

Error Messages/Logs

actions[0] (navigate) failed: permission_required: example.com (0 completed, 2 remaining)

Steps to Reproduce

Environment:

• Claude in Chrome extension v1.0.70 (Beta), ID fcoeoabgfenejglbffodgkkbkcdhcgfn, installed from Chrome Web Store
• Chrome Site Access for the extension set to "On all sites" (verified at chrome://extensions)
• macOS Darwin 25.5.0
• Claude Code CLI (Opus 4.7) as the MCP caller

Repro:

1. From Claude Code, call mcp__Claude_in_Chrome__list_connected_browsers → ✅ returns Browser 1 with a deviceId.

1. Call mcp__Claude_in_Chrome__select_browser({ deviceId }) → ✅ "Connected to browser Browser 1".

1. Call mcp__Claude_in_Chrome__tabs_context_mcp({ createIfEmpty: true }) → ✅ returns a tab on chrome://newtab/ inside a fresh MCP tab group.

1. Call mcp__Claude_in_Chrome__browser_batch with actions:

[
{ name: "navigate", input: { url: "https://example.com", tabId } },
{ name: "computer", input: { action: "wait", duration: 2, tabId } },
{ name: "computer", input: { action: "screenshot", tabId } }
]

1. The first action returns: permission_required: example.com (0 completed, 2 remaining)

1. No "Always allow on this site" popup renders — not overlaid on the page, not in the Claude side panel (verified with ⌘E open before retry), not as a Chrome notification.

1. Settings → Permissions → "Your approved sites" stays at "No sites have been approved yet". The page has no UI to add a site manually (#21723).

Confirmed identical failure on https://example.com (public, no redirect, no auth, no JS dialogs), https://google.com, and the original target https://maheslcm--crmfull.sandbox.my.site.com/...

Things that do NOT fix it:

• Setting Chrome Site Access to "On all sites"
• Granting per-host via Chrome puzzle icon → 3-dot menu → "On <host>"
• Quitting Chrome (⌘Q) and relaunching
• select_browser to re-establish the connection
• Uninstalling the extension and reinstalling fresh from Chrome Web Store (Web Store served the same v1.0.70 back)
• Opening the Claude side panel (⌘E) before the navigate call

This is a continuation of the regression class documented in:

• #53630 (v1.0.69 — Closed but persists in v1.0.70)
• #50606 (v1.0.66+ — "Navigation to this domain is not allowed" variant)
• #21723 (Permissions page lacks "Add site" UI — closes the only escape hatch when popup is broken)

Yesterday-vs-today delta: same workstation, same Chrome, same accounts. Only the extension version changed (auto-updated overnight from pre-1.0.66 to 1.0.70).

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.128 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_