[BUG] Claude for Chrome v1.0.70 returns `permission_required: <domain>` for every MCP-initiated navigation

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?

Claude for Chrome v1.0.70 returns permission_required: <domain> for every MCP-initiated navigation. The approval popup never renders, no badge appears on the extension icon, and no notification is shown. The extension is effectively unusable because there is no path for the user to grant approval to any domain.

This appears to be the same regression class as #50157 and #53630, still present in v1.0.70.

What Should Happen?

Environment

• Extension: Claude in Chrome (Beta) v1.0.70
• Browser: Google Chrome (latest stable)
• OS: macOS (MacBook Air M4)
• Plan: Max
• Account confirmed signed in to extension
• No organization-level admin restrictions

Steps to reproduce

1. From a Claude conversation with browser tools available, attempt navigate to any domain — e.g. https://192.168.11.17 (private) or https://example.com (public).
2. Tool returns: permission_required: <hostname>
3. No approval popup, no toolbar badge, no notification.

Expected behavior

First MCP-initiated action against a previously-unapproved domain should render an 'Always allow actions on this site' approval prompt in the side panel. After approval, subsequent MCP calls to that domain should succeed.

Actual behavior

permission_required is returned silently. No UI to grant approval surfaces anywhere.

Mitigations attempted (none worked)

• Chrome fully quit (Cmd+Q) and relaunched
• Extension updated to v1.0.70
• Switched permission mode from 'Ask before acting' to 'Act without asking' in the side panel dropdown
• Verified service worker is alive (chrome://extensions → Inspect views → service worker shows 'Sin problemas' / no errors)
• Verified account is signed in correctly in the side panel

Failure pattern

Fails on:

• Private IPs (192.168.11.17)
• Public domains (example.com)

This rules out: certificate issues (private IP has self-signed cert, but example.com does not), network reachability, organization allowlist (none configured), and Claude default blocked categories (example.com is not in any blocked category).

Impact

Extension is fully blocked for any new domain. Cannot grant per-site or always-allow permission through any UI. Workaround of switching to 'Act without asking' has no effect — the underlying permission gate still rejects.

Notes

Likely the server-side domain classification at api.anthropic.com/api/web/domain_info/browser_extension is returning a block result without surfacing a renderable approval prompt to the side panel, consistent with the analysis in #50157.

Error Messages/Logs

Steps to Reproduce

1. From a Claude conversation with browser tools available, attempt navigate to any domain — e.g. https://192.168.11.17 (private) or https://example.com (public).
2. Tool returns: permission_required: <hostname>
3. No approval popup, no toolbar badge, no notification.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

4.7

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_