Misleading "blocked by your organization's policy" error when browser control is disabled in Claude Desktop
Summary
Claude-in-Chrome (Claude for Chrome extension driven by Claude Code) returned This site is blocked by your organization's policy for every navigation, including plain public sites. There is no Chrome enterprise policy involved. The real cause was a Claude Desktop setting that disables browser/extension control, which appears to have been toggled on during an app update. The error text attributes the failure to a nonexistent organization/Chrome policy, which sent diagnosis in entirely the wrong direction.
Environment
- OS: Windows 11
- Claude Code (CLI) + Claude for Chrome extension
- Claude Desktop installed on the same machine
What happened
navigateto any URL (a plain public marketing site, and a Google admin site) returned:This site is blocked by your organization's policy.tabs_contextinitially connected and listed tabs, but all navigation was refused with that same message.
Diagnosis the message misdirected
Because the message names an "organization's policy," the natural investigation targeted a Chrome/enterprise policy — all dead ends:
- Chrome policy registry keys (
HKLM/HKCU/WOW6432Node\...\Policies\Google\Chrome, plus the Beta/Dev/Chromium variants) — all absent - Chrome cloud-management enrollment token — none
- Managed/enterprise profile flags — none (normal, unmanaged profile; automation was even running in the user's own Default profile)
- Installed-extension audit, including a VPN/proxy extension with broad permissions — not the cause
None of these were the problem. The actual cause was the Claude Desktop setting blocking browser control, which had been flipped (apparently during an update). Toggling it back cleared the block — although the extension then showed Browser extension is not connected and needed to reconnect (Chrome restart).
Impact
Substantial session time and token usage were lost to diagnosis solely because the error attributes the failure to a Chrome/enterprise policy that does not exist. A user reasonably chases registry policies, Workspace/admin cloud policy, managed-profile state, and extensions — none of which are involved.
Suggested fixes
- Don't silently change the browser-control setting on update. If it must default to off, surface that prominently to the user.
- Fix the misleading text. Instead of
This site is blocked by your organization's policy, report the true cause, e.g.Browser control is disabled in Claude settings — enable it to allow navigation. - Surface the setting's state in the
tabs_context/ connection response so the failure is self-explaining rather than masquerading as an enterprise policy.
_Category: claude-in-chrome / bug._