[FEATURE] Allow whitelisting localhost / 127.0.0.1 in the Claude in Chrome extension (re-filing auto-closed #38378)
Preflight Checklist
- [x] I have searched existing requests — this was previously requested in #38378, which was auto-closed for staleness ("not planned") on 2026-06-09 with the instruction to open a new issue if still relevant. It is still relevant; this is that new issue.
- [x] This is a single feature request
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.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.1in 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.
- Prior request #38378 asked for exactly this in March 2026, gathered agreement in comments, and was auto-closed for inactivity; users were still commenting "please reopen" after closure.
Priority
High - Significant impact on productivity
Feature Category
MCP server integration (Claude in Chrome / browser automation)
Use Case Example
- Claude Code edits a React component in a project running under Docker Compose with hot reload on
http://localhost:3001. - The change is live in the browser within seconds of the edit.
- Claude attempts
navigatetohttp://localhost:3001/to verify the change visually → "This site is blocked by your organization's policy." - The developer has to inspect the UI manually and describe what they see back to Claude, for every iteration.
Additional Context
- Previous (auto-closed) request: https://github.com/anthropics/claude-code/issues/38378
- Environment: macOS 15 (Darwin 24.6.0), Claude Code CLI with the Claude in Chrome extension, observed 2026-07-07. The same limitation was originally reported on Windows 11 in #38378, so it is not platform-specific.