You ask an AI assistant to open or screenshot a page through its Chrome extension, and every attempt returns “Navigation to this domain is not allowed” — even for a site you own and are logged into. The browser is clearly connected, so what’s going on? It’s almost never the website. It’s a permission layer.
chrome://extensions “site access” toggle. Grant that and reconnect. If a permission reset and reinstall still don’t help, the block is account- or environment-level — switch to a direct browser-automation library.The tell-tale sign is that the refusal is blanket and instant: not one site, but every URL you try, including your own, refused immediately with no permission prompt. That rules out “the site blocks bots” (which is selective and usually noisy) and points at a grant that was never given to the assistant.
The assistant app's own settings (tool allow-list). Usually already allowed — layer 1 is rarely the cause.
chrome://extensions → the extension. What people toggle — necessary, but not enough on its own.
Granted INSIDE the extension itself, separate from layer 2. This is the switch people miss. Fix it here first.
All three open and still refused? Account policy or environment gate. Not fixable locally — use direct automation.
Table of Contents
The symptom, precisely
Before changing anything, confirm you have this problem and not a different one. The signature is specific:
- Every URL is refused, not just one — including a domain you own and are logged into.
- The refusal is instant and identical each time: “Navigation to this domain is not allowed.”
- There is no “Allow?” prompt — nothing is asking your consent, because the grant is simply absent.
A single blocked site with a noisy error is probably that site’s own bot rules. A blanket, instant, prompt-less deny is a permission gate.
The three permission layers
Browser automation by an assistant passes through three separate permission layers, and they are easy to confuse:
| Layer | Where it lives | Common state |
|---|---|---|
| 1. Assistant tool permission | The assistant app’s own settings (allow-list of tools) | Usually already allowed |
| 2. Chrome’s extension “site access“ | chrome://extensions → the extension | What people toggle — not enough alone |
| 3. The extension’s own automation grant | Inside the assistant’s browser extension itself | The usual gate |
“Site access: on all sites” in chrome://extensions is layer 2. The automation grant is layer 3 — a separate switch inside the extension.
The quick fix (the common case)
Most cases are layer 3. To fix it:
- Open the assistant’s browser extension itself (its popup/settings) — not the
chrome://extensionspage. - Grant its site permission: allow the specific sites you need, or all sites, inside the extension.
- Reconnect or re-select the browser, then retry.
The most common mistake is setting “site access: on all sites” in chrome://extensions and assuming that’s the whole job. That’s Chrome’s layer 2; the assistant’s automation permission is layer 3, granted inside the extension, separately.
The full diagnostic protocol (when the quick fix fails)
If granting the permission didn’t help, stop guessing and eliminate causes in order — each step tells you something definitive:
- Confirm the connection. If the assistant can list and select your browser, pairing is fine — this is a permission problem, not a connection one.
- Check the assistant’s tool settings. If the browser/navigate tools are allowed there (they usually are, with no “deny” rule), layer 1 is innocent.
- Try a domain you own. One blocked site might be that site’s rules; every site blocked — including yours — is a blanket deny, which means layer 3 or higher.
- Reset the extension’s permissions to default. If nothing changes, the block is not a remembered “deny”.
- Reinstall the extension. A clean reinstall wipes all stored state. If it’s still blocked, the cause is not local extension state at all.
Ruling out antivirus, firewall and network
A frequent wrong turn is blaming antivirus or a firewall. There’s a one-minute test that settles it: open the exact same URLs in a plain, separate browser on the same machine. If those pages load fine, then DNS, TLS, the firewall and antivirus all allow the traffic — because they can’t tell one browser’s request from another’s.
Antivirus blocks the network and throws connection errors. “Not allowed” is a clean application-policy message. Different layer, different symptom.
Recognizing an environment-level block
Put the evidence together. If the refusal survives a permission reset and a full reinstall, a plain browser reaches the same sites, and your tool settings allow the action — then every cause you can touch locally is eliminated. What remains is above your machine:
- an account-level permitted-sites policy,
- a feature gated or disabled for your account, or
- an environment/deployment policy that disables assistant navigation by design.
None of those are fixable from your computer, Chrome, or the extension. Recognizing this early saves hours of toggling switches that were never the problem.
If a reinstall changes nothing and a plain browser works, stop toggling — the block is above your machine.
The workaround that always works: drive a browser directly
When the assistant’s extension is blocked above your machine, stop fighting it and use a direct browser-automation library such as Playwright instead. It launches and controls its own browser with no extension and no permission gate — it can navigate, screenshot, extract content, and fill forms:
from playwright.sync_api import sync_playwright
with sync_playwright() as pw:
browser = pw.chromium.launch(headless=True)
page = browser.new_page()
page.goto("https://example.com", wait_until="domcontentloaded")
print(page.title())
page.screenshot(path="page.png", full_page=True)
browser.close()
Code language: Python (python)That fresh browser isn’t logged into your accounts. If you need authenticated pages (a private preview, an admin view), launch it against your existing browser profile (a “persistent context”) so it inherits your cookies and sessions — just close the browser first, since the profile locks while it runs. That “use your own signed-in session” principle is the same one that makes it safe to back up your AI chat history from the live app. (If you use Playwright regularly, note that its browser cache is shared, not per-project, so you don’t re-download Chromium for every environment.)
The short version
If Claude can’t access websites in Chrome and refuses every URL instantly with no prompt, it’s a missing permission, not a site block. Automation passes through three layers: the assistant’s tool permission (usually fine), Chrome’s chrome://extensions site access (what people toggle), and the extension’s own automation grant (the usual culprit) — grant that one inside the extension and reconnect. If a permission reset and reinstall don’t help, a plain browser reaches the same sites, and your tool settings allow the action, the block is account- or environment-level and not fixable locally. Then switch to a direct browser-automation library, which works without the extension.
Frequently Asked Questions
Why is even my own website blocked?
Because the refusal is about the assistant’s permission to drive any page, not about a specific site. A blanket deny of every URL, including your own, means the automation grant is missing at the extension layer or above — not that your site is refusing the assistant.
I allowed it in chrome://extensions — why does it still fail?
That sets Chrome’s “site access” layer (layer 2). The extension has its own, separate automation permission (layer 3); you grant that inside the extension itself, not on the chrome://extensions page. Missing layer 3 is the most common cause.
Could antivirus or a firewall be the cause?
Almost never for this specific message. Open the same URL in a plain browser on the same machine — if it loads, security software is allowing the traffic and isn’t your problem. Antivirus and firewalls throw connection errors, not a clean “not allowed” policy message.
Is it a bug in the assistant?
Usually not. If the browser connects and the tools are allowed, the block is a deliberate permission gate — it protects you from letting an assistant browse without consent. Grant the permission or, if it’s environment-level, use the direct-automation workaround.
What if nothing local fixes it?
Then it’s account- or environment-level and not fixable from your machine — an account policy, a gated feature, or a deployment that disables assistant navigation by design. Switch to a direct browser-automation library, which drives its own browser without the extension.
