Chrome 151 blocks DevTools extensions on other extension pages: supported migration path?

[c luo]

Hi,

I am the developer of Storage Area Viewer:

https://chromewebstore.google.com/detail/storage-area-viewer/fcbndbpibgeafoogbmbcljcmgakaniae

It is a Manifest V3 DevTools extension. When a developer inspects a chrome-extension:// page, it adds a DevTools panel for inspecting chrome.storage areas (local, sync, session, and managed) and editing data where permitted.

Problem

On macOS with Chrome 151.0.7922.109, the Storage Area Viewer panel no longer appears when DevTools is opened for another extension's chrome-extension:// page.

The current Chrome Web Store release is 1.0.3. I also reproduced the problem with an enabled unpacked 1.0.5 development build.

What I found:

1. For a normal web page target, the extension's devtools_page can load.
2. For Storage Area Viewer's own extension page, it can also load.
3. For a chrome-extension:// page belonging to a different extension, devtools_page is never loaded. The extension therefore has no opportunity to display an error, fallback UI, or migration notice.
4. Launching Chrome with --extensions-on-extension-urls restores the previous behavior.

This appears to be related to the following DevTools Frontend change. RegisteredExtension.isAllowedOnTarget() now prevents a DevTools extension from loading on a different extension origin:

https://chromium.googlesource.com/devtools/devtools-frontend/+/951c1e9f60ad86eb0a6b247b6cdf8b2f6e3f301d

I understand that cross-extension code execution or data access may present a security risk. However, the current implementation does not only restrict inspectedWindow.eval(); it prevents the entire devtools_page from being registered. This effectively ends a category of developer tools that previously worked.

Why the native Extension Storage panel is not a complete replacement

Chrome 132 introduced Application > Storage > Extension Storage:

https://developer.chrome.com/docs/devtools/storage/extensionstorage

The native panel provides basic viewing, filtering, creation, editing, and deletion. Storage Area Viewer also provides debugging-focused capabilities:

- A live timeline of storage add, update, and delete events with timestamps
- Structured old/new JSON diffs that highlight the exact changes
- Search across both keys and serialized values, including an exclusion filter
- Pinning keys that need to be monitored continuously
- A collapsible JSON detail view
- A full JSON editor with formatting and one-click copying
- Virtualized lists for working with large storage datasets during continuous debugging

These features make it a storage debugger rather than only a data table.

I would appreciate guidance from the Chrome Extensions / DevTools team:

1. Is this an intentional and permanent security policy change?
2. Is there a public design document, migration notice, or Chromium issue describing it?
3. Could there be an explicit user-consent mechanism allowing a DevTools extension to access selected extension targets, such as a permission, extension ID allowlist, or confirmation prompt in DevTools?
4. Could Chrome expose a restricted DevTools API that only reads and modifies the target extension's chrome.storage data, without allowing arbitrary JavaScript execution?
5. Is --extensions-on-extension-urls a supported and stable development path? Can it be enabled through an enterprise policy or dedicated development configuration?
6. If this DevTools extension architecture is no longer supported, what migration path does the team recommend?

I would like to understand the security reasoning behind this change and find an officially supported implementation that follows the new security model while preserving these debugging capabilities.

Thank you.