[BUG] Claude in Chrome (from Claude Desktop): every domain except docs.google.com denied, no approval popup, server returns "allow"

Status Open
Reported on v2.1.275
Maintainer reply None cached
Activity 0 comments · opened Sep 21, 2026

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?

Environment: macOS, Claude desktop app (Code tab), Claude in Chrome 1.0.94, Chrome 153. Same account in both. Extension site access: "On all sites."

Symptoms:

  • navigate returns "Navigation to this domain is not allowed" for plus.lexis.com, wikipedia.org, law.justia.com, courtlistener.com, drive.google.com.
  • screenshot / get_page_text on a user-opened plus.lexis.com tab return "Permission denied for this action on this domain" immediately.
  • No permission popup ever appears. docs.google.com works; it was approved once via popup on 2026-09-20.

Evidence the server is not blocking:
POST api.anthropic.com/api/web/url_hash_check/browser_extension returns
category "category0", org_policy "allow", policy_source "account_settings"
for plus.lexis.com. Request-Ids: req_011CfGmQSVcfqKfTZpfDibre, req_011CfGmQfQFTKFRP5vwbYQhR, req_011CfGmR76q1BZPwv6rjRfPM.
The extension's permissionStorage holds a single grant (docs.google.com, surface "mcp_popup").

What Should Happen?

Expected: an approval popup for a new domain, as happened for docs.google.com.
Tried: signed out and back in, new tab group, pasted the URL in chat, dragged the tab into the Claude group. No change. No domain rules in Claude Code settings.

Error Messages/Logs

Related: #55706, #74696, #92043, #66074, #94545.

Steps to Reproduce

  1. Install Claude in Chrome 1.0.94 and sign in with the same account as the Claude desktop app (macOS). Confirm chrome://extensions > Claude > Site access is "On all sites."
  2. In the Claude desktop app (Code tab), start a session and ask Claude to use the Chrome tools.
  3. Have Claude call tabs_context_mcp with createIfEmpty: true. This works and returns a tab.
  4. Have Claude call navigate to https://www.wikipedia.org/ on that tab.

Result: "Navigation to this domain is not allowed". No popup appears in Chrome.

  1. Repeat step 4 with https://plus.lexis.com/, https://law.justia.com/, https://www.courtlistener.com/ and https://drive.google.com/.

Result: same error each time, returned in about 300 ms.

  1. Manually open any of those sites in a Chrome tab and drag the tab into the Claude tab group. Have Claude call computer (screenshot) or get_page_text on it as a standalone call.

Result: "Permission denied for this action on this domain" immediately. No popup appears.

  1. Have Claude call navigate to https://docs.google.com/document/u/0/.

Result: succeeds. This domain was approved once through a popup on 2026-09-20.

  1. With DevTools open on the extension's service worker (Network tab), repeat step 4 for plus.lexis.com.

Result: POST /api/web/url_hash_check/browser_extension returns org_policy "allow", category "category0", yet the tool call is still refused.

Frequency: 100% of attempts over two days, across a sign-out/sign-in and a new tab group.

Claude Model

Other

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown. It has not worked for me on any version for domains other than docs.google.com. The extension updated from 1.0.91 to 1.0.94 on 2026-09-20. The one approval popup I ever saw (docs.google.com) appeared on 1.0.94 that day. Other reports describe this as a regression starting around extension 1.0.66 (April 2026): #50606, #43255.

Claude Code Version

2.1.275 (bundled in Claude desktop app 2.2553.1, macOS 26.6.2). Claude in Chrome extension 1.0.94.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

  • Not an account or server block: the url_hash_check response for the refused domain is org_policy "allow", category "category0", policy_source "account_settings".
  • Not Chrome site access: extension is set to "On all sites"; file URL access is on.
  • Not Claude Code permissions: all mcp__claude-in-chrome__* tools are allowed in .claude/settings.local.json, and no domain rules exist in any settings file.
  • Tab management works through the same connection (tabs_context_mcp, tabs_create_mcp, tabs_close_mcp). Only navigate and page actions are refused.
  • The refusal is immediate (about 300 ms per the desktop app's main.log, which records only "Tool call error: navigate" with no reason).
  • Extension console during the refused calls shows only "Unchecked runtime.lastError: Debugger is not attached to the tab", meaning the extension never attached to the tab. No error explains the denial.
  • Earlier the same week the extension reported "not connected" until Chrome was restarted, because version 1.0.94 was queued behind a long-running Chrome session. After the restart it connected, and this issue began.
  • Personal Pro/Max account on a personal Mac. No employer or organization management. (Edit to match your plan.)
  • Request-Ids from the three url_hash_check calls are listed above, for server-side lookup.

View original on GitHub ↗