You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Claude in Chrome extension cannot interact with pages served on localhost / 127.0.0.1, and there is no way to whitelist them. Navigation attempts fail with a permission error ("This site is blocked by your organization's policy."), and the extension's site-permissions UI does not accept localhost entries.
This blocks the single most common development loop: Claude Code edits frontend code, a local dev server hot-reloads it, and Claude verifies the result with a screenshot. With localhost blocked, either a human has to eyeball every iteration on Claude's behalf, or the change has to be deployed to a public staging domain (which can be whitelisted) just to be looked at — turning a seconds-long hot-reload loop into a minutes-long deploy loop.
Proposed Solution
Allow localhost / 127.0.0.1 origins (ideally with port granularity, e.g. localhost:3001) to be added to the extension's allowed sites like any other origin — from the extension's options/site-permissions UI, and/or via a CLI command in Claude Code.
Local origins are the developer's own machine; they are arguably the lowest-risk targets for browser automation, yet they're the only ones that can't be granted at all.
Alternative Solutions
Tried adding localhost / 127.0.0.1 in the extension's site permissions — not accepted.
Current workaround: deploy the change to a staging domain that is whitelisted, so Claude can screenshot it there. This costs a full deploy cycle per UI iteration.
Preflight Checklist
Problem Statement
The Claude in Chrome extension cannot interact with pages served on
localhost/127.0.0.1, and there is no way to whitelist them. Navigation attempts fail with a permission error ("This site is blocked by your organization's policy."), and the extension's site-permissions UI does not accept localhost entries.This blocks the single most common development loop: Claude Code edits frontend code, a local dev server hot-reloads it, and Claude verifies the result with a screenshot. With localhost blocked, either a human has to eyeball every iteration on Claude's behalf, or the change has to be deployed to a public staging domain (which can be whitelisted) just to be looked at — turning a seconds-long hot-reload loop into a minutes-long deploy loop.
Proposed Solution
Allow
localhost/127.0.0.1origins (ideally with port granularity, e.g.localhost:3001) to be added to the extension's allowed sites like any other origin — from the extension's options/site-permissions UI, and/or via a CLI command in Claude Code.Local origins are the developer's own machine; they are arguably the lowest-risk targets for browser automation, yet they're the only ones that can't be granted at all.
Alternative Solutions
localhost/127.0.0.1in the extension's site permissions — not accepted.Priority
High - Significant impact on productivity
Feature Category
MCP server integration (Claude in Chrome / browser automation)
Use Case Example
http://localhost:3001.navigatetohttp://localhost:3001/to verify the change visually → "This site is blocked by your organization's policy."Additional Context