Claude in Chrome: Support wildcard/pattern domain matching for site permissions

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The Claude in Chrome extension requires per-domain approval for site access. When working with preview deployments (e.g., Vercel, Netlify, Cloudflare Pages), every deployment gets a unique subdomain like:

• my-app-abc123-team.vercel.app
• my-app-def456-team.vercel.app
• deploy-preview-42--my-app.netlify.app

This means every single preview deployment triggers a new permission prompt, even with "Act without asking" mode enabled. There is no way to approve a pattern like *.vercel.app or *.netlify.app.

This makes Claude in Chrome impractical for common development workflows involving preview deployments, per-branch environments, or dynamic staging URLs.

Proposed Solution

Support wildcard or pattern-based domain matching in the Chrome extension's site permissions. For example:

• *.vercel.app — approve all Vercel preview deployments
• *.netlify.app — approve all Netlify preview deployments
• *.staging.mycompany.com — approve all staging subdomains
• *.localhost — approve all local dev subdomains

This could be exposed in the extension settings UI or as a configuration option.

Alternative Solutions

• Vercel Preview Deployment Suffix: Replaces vercel.app with a custom domain, but each preview still gets a unique subdomain with a hash, so this doesn't help.
• Manual approval per deployment: Current workaround, but extremely tedious for active development.
• LevelDB direct writes: Documented in #26779 as a security vulnerability, doesn't support wildcards anyway, and requires closing Chrome.

Priority

High - This is blocking productive use of Claude in Chrome for development workflows

Feature Category

Configuration and settings

Use Case Example

As a developer, I use Vercel preview deployments to test changes before merging. I want Claude to help me test and verify these deployments using browser automation. Currently, I need to manually approve every single preview URL, which defeats the purpose of autonomous browser automation.

Additional Context

• Related (but different scope): #16613, #15260, #11972, #9329 — these all address WebFetch domain wildcards in Claude Code settings, not the Chrome extension's own site-level permission system
• Chrome's enterprise URL patterns already support [*.]domain.com syntax, so there's precedent for this in the Chrome ecosystem