How to limit chrome extension site access to a single site

Setting a hard allowlist for your voice extension is the correct privacy default, and learning to limit chrome extension site access to one domain is more mechanical than most people expect. Open chrome://extensions, click the Details button for your dictation tool, and find the Site access section, where you can switch the behavior from On all sites to On specific sites and type a single domain such as chatgpt.com. The extension keeps running, keeps its hotkey, keeps its vocabulary, and simply no longer sees any other origin. If you use one surface for most of your spoken input, this one-minute change gives you the entire security benefit of a closed system, because the content script now has exactly one place it is allowed to live.

The lockdown is stronger than it sounds because it is enforced by the browser rather than by the tool. The extension cannot talk to a page it was not invited to, which means the pages of your banking app, your email, and your document library are structurally out of reach, regardless of what the code wants to do. This is the security model working as designed: instead of trusting the vendor to behave, you trust the browser to enforce a boundary, which is the difference between hoping a tool is honest and knowing it cannot act beyond the line. The same enforcement is also why permission scoping survives extension updates, because Chrome applies site access independently of the code version.

The cost of the lockdown is a shift in mindset from all-sites convenience to list discipline. From now on, dictation on a new site is not just a different page, it is a new entry that must be deliberately granted, and every grant is a decision about your data rather than a default. That framing is exactly what most people want from a privacy posture, but it requires one habit to keep it honest: never leave the allowlist at all-sites again just because a single page was inconvenient. The lockdown is not a one-time setting; it is a policy, and policies only work when you treat their exceptions as explicit decisions.

Naming what you gave up prevents a surprise later, so run the inventory while the lockdown is fresh. The big loss is obvious: dictation stops on every domain outside the list, including sites you visit once a month but have not thought about, such as a wiki, a ticketing portal, or a webmail client. The smaller loss is subtler, and it is the loss of the auto-detect flow, where the extension notices any focused text field and offers capture without being asked. On a single-site allowlist, that offering simply does not exist elsewhere, and you may not notice until you press the hotkey and nothing responds at all.

Two features typically keep working even outside the allowlist, and knowing which is which saves debugging later. The extension's own options page and its popup generally run on the extension's own origin, so testing the microphone there still works, and any dictation that happens inside a browser-native surface such as a settings page or a PDF viewer is governed by different rules entirely. The feature that genuinely dies is typed insertion into a third-party page, which is precisely the feature the allowlist was designed to constrain. Inventory the surface you care about, a chat composer, a doc editor, a form, and confirm each one is inside the list, because a feature you cannot name is a feature you cannot verify.

Write the inventory down while it is accurate. A list of your five real dictation surfaces, with each site's exact domain, turns the policy from a vague restriction into a precise map, and the same map becomes the checklist you use when a page fails. Many users find their actual surface is smaller than they assumed, often one chat tool and one editor, which is a pleasant discovery because it means the lockdown costs them almost nothing while granting them real protection. The inventory is also the answer to the question every policy deserves: what exactly did I trade, and was it worth it?

The failure mode you will actually meet is the silent blackout: you open a new site, press the capture key, and nothing appears in the field, with no error, no red badge, and no hint that the extension even noticed your press. The reason is structural, not malicious: the extension listened, transcribed, and then attempted to deliver text into an origin it is not permitted to touch, so the insertion simply fails. From the outside, the experience is indistinguishable from a broken extension, which is why the lockdown is sometimes blamed for bugs it never caused. Learning the blackout as a known pattern is the survival skill of the narrow allowlist.

The diagnosis is one click. Open the address bar site information panel and look for the extension listing, or open chrome://extensions and check the chatgpt.com entry beside your tool, and the answer presents itself: the domain is missing from the list, or sits under an entry that does not match, such as an www. prefix when the list holds the bare domain. Mismatched origins are the second-greatest cause of a blackout after a missing entry entirely, and they appear when a site redirects to a subdomain you did not grant. One minute on the allowlist page, and the mystery resolves into a simple grant, which is precisely why the fix is always a settings step rather than a reinstall.

Train yourself to stop the panic loop the first time it happens. Before you reload the extension, before you clear your cookies, and before you announce a bug to anyone, run the two-item check: is this domain in the allowlist, and does it match exactly? The check takes ten seconds and resolves ninety percent of blackouts, and it will give you the correct vocabulary for the other ten percent, which are the cases where a site genuinely refuses injection for its own reasons. A narrow policy is a ledger of deliberate decisions; every blackout is just an entry you had not listed yet, and the ledger is what keeps the policy meaningful.

The allowlist should be grown by merit, not by mood, and the merit test is straightforward: a site earns permanent access when dictation on it has become part of your weekly routine. The threshold matters because each permanent entry is a standing invitation for the extension to run there, so a throwaway portal you visited for one form does not deserve the same treatment as the editor you live in. When you hit a site for the second time in a month, add it, and note in your head why it qualifies: it holds the text fields you write into, and you will speak there again. Sites where you only read never need access at all, because a reading page has nothing for dictation to enter.

Separate the permanent tier from the occasional tier and behave accordingly. For occasional surfaces, the better approach is the on-click option, where the extension gains access only for the current session after you explicitly approve it, giving you the benefit without a standing grant. This tier keeps the list small, which keeps the audit honest, and it preserves your ability to dictate into the random tool a colleague links you without extending a permanent invitation. Users who run both tiers report the sweet spot: five permanent sites, one-click access for everything else, and an allowlist that stays small enough to remember and narrow enough to defend.

Review the list on the same quarterly cadence you use for the whole extension audit. Open the Site access settings, look at each domain and ask whether you have dictated there in the past four weeks, and remove the entries that no longer earn their place. The removal is instant and painless, and it is the ritual that keeps the lockdown from quietly becoming everything again, because lists, like deadlines, expand to fill the attention you give them. A small, current, deliberately grown allowlist is the finish line of this whole exercise: maximum privacy on a per-site basis, with the feature you use most.

Every time you edit the allowlist, run the post-edit walk, and the reason is that a policy change can break a site in a way you do not notice until you need it. The walk is five minutes: open each site on your inventory, click into a real field, press the hotkey, and confirm the words land. Start with the most important surface, then the rest, then one site you added in the same session to confirm the grant took effect. If a daily site fails, the walk catches it while the context is still in your head, instead of during the client call where you discover the capture key silently does nothing.

The walk also validates the mechanics of the grant, not just the presence of it. A site can appear in the allowlist and still refuse insertion because Chrome matched the wrong origin or because the page reloaded before the extension registered, so the real test is behavioral: does dictation actually type on this page right now? If a listed site fails, reload the page and retry, then check the exact origin string, and only then suspect the site itself. In practice the failure is almost always a reload-required issue, which is why the walk includes one reload pass over the sites you added before the test.

After the walk, pin the result so your future self can compare. Note the date, the list size, and any site that misbehaved, and if a site recurs as a problem, that is your signal to test it with the on-click option instead of permanent access. The walk is a small ritual with an outsized return: it converts every policy edit from a gamble into a procedure, and it is the habit that lets you keep the lockdown tight for years. A narrow allowlist that is verified on the day you change it is a policy you can trust, and trust is the whole point of the lockdown.