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

[galejandroz]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

The Claude in Chrome sidebar shows "Can't access this page — This site is blocked by your organization's policy" on every site, including google.com.

This is a personal machine with no enterprise policies, no MDM, no antivirus, and no managed Chrome profile.

• chrome://policy — empty
• chrome://management — not managed

Steps to reproduce:

1. Open any website (e.g. google.com)
2. Open the Claude sidebar
3. Error: "This site is blocked by your organization's policy"

Environment:

• OS: Ubuntu 24.04.4 LTS (kernel 6.18.5, x86_64)
• Chrome: 148.0.7778.167 (Official Build) (64-bit)
• Claude in Chrome extension: v1.0.70
• Plan: Pro (individual)
• Chrome profile: personal, no enterprise policies

Related issues: #41034, #50157

What Should Happen?

The Claude sidebar should load normally and be able to interact with any website without being blocked.

Error Messages/Logs

Can't access this page
This site is blocked by your organization's policy.

Steps to Reproduce

1. Open any website (e.g. google.com)
2. Open the Claude in Chrome sidebar
3. Sidebar shows: "Can't access this page — This site is blocked by your organization's policy"

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.138

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. [Bug] Claude for Chrome extension incorrectly blocking non-restricted sites with false "organization policy" error #59494
2. [BUG] Bug: Claude in Chrome — all sites blocked in Cowork mode (was working previously) #41034
3. Claude in Chrome MCP blocked on all https:// sites — org_policy: "block" #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

[octopuxltd]

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.

[octopuxltd]

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!

[nsirk-ardneyatt]

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.

[EHxuban11]

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

[krystian-dev548]

#41034