As of Chrome version 154, applying runtime_blocked_hosts to an extension that has the debugger permission completely disables chrome.debugger.attach() on all targets, according to the Chromium policy definition. You can also block the debugger permission itself. Either way, decide which extensions truly need it.
Why the debugger permission is sensitive
The debugger permission gives an extension access to the Chrome DevTools protocol through the chrome.debugger API, which is the same interface automation and inspection tools use. In general terms, an extension that can attach to a tab can see and influence what the page does. That is why reviewers treat it as a high-risk permission, and why a legitimate use is usually a developer or testing tool.
We have not tested what a specific extension can read once attached, so treat the above as the reason for caution, not as a measured result.
What Chrome's policy offers
The Chromium definition of ExtensionSettings says two relevant things:
- Per-extension entries may include
blocked_permissions, a list of permissions the extension is not allowed to use, andruntime_blocked_hosts, a list of URL patterns the extension cannot touch. - As of Chrome 154, applying
runtime_blocked_hoststo an extension with thedebuggerpermission completely disableschrome.debugger.attach()on all targets.
That second point is a behavior change worth noting. It means a host block that looks narrow can have a broad effect on a debugging extension, and that you cannot assume host patterns will carve out a safe subset of sites for such an extension.
Three ways to handle it
| Approach | Effect | Use when |
|---|---|---|
Add debugger to blocked_permissions for the extension | Extension may not use that permission | The extension should not debug at all |
Apply runtime_blocked_hosts to the extension | On Chrome 154 and later, attaching is disabled everywhere for that extension | You want to turn off attach without removing the extension |
| Block the extension | It is disabled | The extension has no legitimate need |
Test on your own browser versions, because the 154 behavior only applies from that release.
A short procedure
- Search your inventory for extensions that request
debugger. You can read each manifest or use your management console's report. - Sort them into development tools and everything else.
- For development tools, limit the group that receives them and keep them off production access profiles.
- For everything else, block the permission or the extension.
- Add a review date. Debug-capable extensions deserve a shorter cycle.
For host patterns in general, read blocked hosts and blocked permissions.
Developers still need tools
Blocking debugger for everyone would break legitimate testing. A more realistic split is a separate developer profile or group with a tighter list of approved debug extensions and no access to production sessions in that profile.
Documentation for reviewers
When you approve a debugging extension, record why it needs the permission, which group receives it, and which browser versions you tested. A one line note is enough. If the extension later changes publisher or adds permissions, that note tells the reviewer what the original reasoning was and whether it still applies.
Quick check
Does this apply on older Chrome versions?
The documented behavior starts at version 154. Verify what your fleet does on older versions before depending on it.
Is the debugger permission always malicious?
No. Developer and testing tools use it legitimately. It is high risk because of what it can do, so approve it deliberately.
Sources
Last reviewed: 19 October 2026.
