blockedUrlPattern: hostname patterns with a regexp group are enforced for direct navigation but not for redirects

Description of the bug

A --blocked-url-pattern whose hostname uses a URLPattern regexp group is accepted silently, and navigate_page refuses a direct navigation that matches it. But when an allowed page answers with an HTTP redirect to a URL matching the same pattern, the redirect is followed and the blocked page loads. The same pattern written with an exact hostname is enforced in both cases.

So a user who writes a range (for example all of 127.0.0.0/8) gets protection for direct navigation only, with no warning that redirects are not covered.

Measured results

Pattern	Direct navigation	Redirect from an allowed page
*://127.0.0.1:*/* (exact host)	refused	refused
*://(127\.\d+\.\d+\.\d+):*/* (regexp group)	refused	loads

new URLPattern("*://(127\\.\\d+\\.\\d+\\.\\d+):*/*").test("http://127.0.0.1:8000/") is true in Node 24, so the pattern itself is valid and matches.

Same result on chrome-devtools-mcp 1.9.0 (npm) and on a source build of main at 882f93e (2026-09-18).

Notes

• Possibly related but different code path: #2767 (URL policy across redirects in the Node-side resource loader).
• Separate observation, not a bug in this project: a partial wildcard on a numeric host such as *://127.*:*/* matches nothing at all, because URLPattern canonicalizes 127.* as an IPv4 address (new URLPattern("*://127.*:*/*").hostname is 0.0.0.127*). A sentence in the option's documentation would save users from that one too.

Reproduction

1. Serve any page locally: python3 -m http.server 8000 --bind 127.0.0.1
2. Start the server with: --isolated --headless --blocked-url-pattern "*://(127\.\d+\.\d+\.\d+):*/*"
3. navigate_page to http://127.0.0.1:8000/
   Result: "Unable to navigate in the selected page: Navigation to http://127.0.0.1:8000/ is blocked by blocklist/allowlist rules." The local server logs no request. (Correct.)
4. navigate_page to https://httpbin.org/redirect-to?url=http%3A%2F%2F127.0.0.1%3A8000%2F
   Result: "Successfully navigated", location.href is http://127.0.0.1:8000/, and the local server logs the request. (Unexpected.)
5. Restart with --blocked-url-pattern "*://127.0.0.1:*/*" and repeat step 4.
   Result: net::ERR_INTERNET_DISCONNECTED, the page stays on the error page, and the local server logs no request. (Correct.)

Expectation

Either the regexp-group pattern is enforced on redirects and subresources as it is on direct navigation, or the server rejects (or warns about) patterns that the network-level blocking cannot enforce, and the option's documentation says which pattern forms are supported.

MCP configuration

"args": ["-y", "chrome-devtools-mcp@1.9.0", "--isolated", "--headless", "--blocked-url-pattern", "://(127\.\d+\.\d+\.\d+):/*"]

Chrome DevTools MCP version

1.9.0 (npm); also main at 882f93e

Chrome version

153.0.8010.48

Coding agent version

n/a (reproduced with a plain MCP SDK client)

Model version

No response

Chat log

No response

Node version

v24.21.0

Operating system

No response

Extra checklist

• I want to provide a PR to fix this bug

Start with the --blocked-url-pattern handling and the navigate_page entry point, then reproduce the redirect and direct-navigation cases using the URLPattern examples in the issue. Trace how redirect requests are checked compared with direct navigation, and define done as consistent enforcement for regexp-group patterns or an explicit warning/rejection with documented supported forms.