[FEATURE] Allow whitelisting localhost / 127.0.0.1 in the Claude in Chrome extension (re-filing auto-closed #38378)

Open 💬 0 comments Opened Jul 7, 2026 by hrosspet

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.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.
  • 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

  1. Claude Code edits a React component in a project running under Docker Compose with hot reload on http://localhost:3001.
  2. The change is live in the browser within seconds of the edit.
  3. Claude attempts navigate to http://localhost:3001/ to verify the change visually → "This site is blocked by your organization's policy."
  4. 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.

View original on GitHub ↗