[BUG] Claude in Chrome — "blocked by your organization's policy" on all sites (personal Ubuntu machine, no managed policies)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/59494
2. https://github.com/anthropics/claude-code/issues/41034
3. https://github.com/anthropics/claude-code/issues/51599

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Claude wrote this comment for me after much attempted bugfixing:

+1 on macOS / Max 20x. Adding details in case they help triage.

Environment

• macOS (personal Mac, not managed)
• Chrome 148.0.0.0
• Claude in Chrome extension v1.0.71
• Plan: Max (20x), 5h utilization 0.11, 7d utilization 0.07
• chrome://policy empty
• chrome://management not managed
• No content blockers running

Symptoms

Same Can't access this page — This site is blocked by your organization's policy wording on every website.

The only place the sidebar renders chat at all is Chrome's new tab page (chrome://newtab), presumably because there's no URL there for the extension to classify. From the new tab page, chat works — but any navigation request returns the same org-policy error string in Claude's response, so the extension never actually takes the user anywhere.

Sidebar on claude.ai itself shows the blocked error (matches #50157).

Ruled out (none fixed it)

• Fresh extension reinstall
• Sign out / sign back in on the extension
• Full Chrome quit + Claude desktop app quit + relaunch
• Buying £5 of usage credits — no effect

From the sidepanel network panel

Response headers on POST /v1/messages?beta=true (from a working chat request on the new tab page):

Anthropic-Ratelimit-Unified-Status: allowed
Anthropic-Ratelimit-Unified-5h-Status: allowed (utilization 0.11)
Anthropic-Ratelimit-Unified-7d-Status: allowed (utilization 0.07)
Anthropic-Ratelimit-Unified-Overage-Status: rejected
Anthropic-Ratelimit-Unified-Overage-Disabled-Reason: out_of_credits

Flagging the out_of_credits / Overage-Status: rejected pair in case the extension is using overage status as a signal to gate browsing capability. Likely a red herring — user is on Max 20x at single-digit utilization with credits toggled on, so out_of_credits is misleading on its own terms, and topping up the balance didn't change behaviour.

Also seeing repeated claude_chrome.bridge.peer_disconnected events posted to Segment from the service worker, even when the sidebar appears connected and is responding to chat.

POST /api/web/url_hash_check/browser_extension calls return 200 OK. Didn't capture the response body before the sidebar fully degraded — worth checking what that endpoint returns for affected users, as the name suggests it's the gate that's failing.

Bottom line

Same generic error string across at least two OSes (Linux for OP, macOS for me) and two plan tiers (Pro, Max 20x). Either a single server-side bug surfacing through multiple failure modes, or the string is a catch-all for an unrelated class of issues. Worth fixing the wording either way — it sends users debugging Chrome enterprise policy, MDM profiles, antivirus, etc. for something that has nothing to do with any of that.

SOLUTION! (for me at least)

This sounds ridiculous now, but it shows how confusing and hard to find the options are:

In my Claude desktop app > Settings, there's a menu option called "Claude… [Beta]"

That's actually a truncation of "Claude in Chrome settings [Beta]" – and hidden in there is a site permissions setting that blocks the Chrome extension by default. 🤦‍♂️

I changed that setting, and it worked.

Literally hours wasted with Claude itself unable to debug the problem, all because of some bad content design.

If you have this issue too, I hope this solves it!

Confirming this is still reproducing in v1.0.75 — and on macOS, not just Ubuntu. It's also broader than navigation: every agent action is denied.

Environment

• Claude in Chrome (Beta) v1.0.75, Chrome on macOS
• Personal, unmanaged machine: no MDM/Jamf, chrome://policy is empty, extension self-installed (active "Remove" button, no "Installed by your administrator" badge)
• Reproduced across two separate Chrome profiles

Repro

1. Via the agent, navigate to https://example.com → "This site is blocked by your organization's policy."
2. Manually open any logged-in web app, set the extension's Site access to "On specific sites" (+ Allow access to file URLs), and reload.
3. Via the agent, run get_page_text / read_page / screenshot on that tab → "Permission denied for reading page content on this domain" (and "Permission denied for this action on this domain" for screenshots).

Tried, no effect: fresh reinstall (v1.0.75), granting site access, Allow file URLs, page reload, re-login, a second Chrome profile.

The "organization's policy" wording is misleading — there is no managed policy on this device. Net effect: the extension can't navigate to or read any page, so all browser automation is blocked. Same underlying issue as #41034 and #50157.

I have had this bug for a few months...

https://github.com/anthropics/claude-code/issues/41034

Adding a data point that reproduces this on macOS (this issue is currently filed from Ubuntu) plus a related symptom that may share a root cause.

Environment

• macOS (Darwin 25.5.0)
• Claude Code: 2.1.222
• Claude in Chrome extension: v1.0.85 (installed, connected, per Settings → Permissions)
• Personal account, no org/MDM/managed Chrome profile
• Settings → Permissions → "Your approved sites" = empty ("No sites have been approved yet")

What happened
Via the Claude Code MCP navigate tool (not the sidebar UI), navigating to docs.anthropic.com — an ordinary, presumably-trusted domain — failed immediately:

This site is blocked by your site permissions.

The tab never left chrome://newtab, and no first-visit approval prompt was ever shown for the user to approve the site. This happened on the very first navigation attempt in a fresh MCP tab group — there was no prior denial to explain the block.

Why I think this is the same bug (or a close sibling)

• Same shape as this issue: blocked on an ordinary site, no org/MDM policy present, error text framed as a policy/permissions block rather than a real per-site decision.
• Also matches #27073's core complaint: the domain-approval UI (update_plan / first-visit prompt) never renders at all — navigate just returns a block/deny with nothing for the user to approve. In my case the approved-sites list is empty, so every site should trigger a first-visit prompt, and none does.
• Settings → Permissions has no way to manually add a site (matches #21723) — the first-visit prompt is supposed to be the only path to approval, and that path isn't firing.

Net effect: with a personal account and an empty approved-sites list, Claude in Chrome MCP navigation is completely non-functional — every domain is blocked at the first hop with no UI ever offered to grant access.

Related: #27073, #21723, #75289 (localhost specifically, same "blocked" framing)