Terminal link clicks open Chrome instead of the default browser (Safari) with debugByLinkOptions unset

Summary

Clicking an http(s) link in the VS Code integrated terminal opens it in Google Chrome with the debugger attached instead of the configured macOS default browser (Safari). The interception happens even though debug.javascript.debugByLinkOptions is left unset (i.e. at its default), and there is no obvious indication that the JS debugger is the component handling the click.

This is the same surprise reported back in #427 ("clicking links now opens chrome (not my default browser)"), filed here as a standalone report because the behavior persists in current VS Code.

Environment

• VS Code 1.125.1 (arm64)
• macOS 26.5.1 (25F80), Apple Silicon
• Default browser: Safari — confirmed authoritative via LSCopyDefaultHandlerForURLScheme("https") -> com.apple.Safari
• debug.javascript.debugByLinkOptions: unset (default)
• $BROWSER, $VISUAL, $EDITOR, CHROME_PATH, PUPPETEER_EXECUTABLE_PATH all empty
• No browser-router app (Finicky/Velja/Choosy), no MDM URL profile, no workbench.externalUriOpeners

Steps to reproduce

1. Set the macOS default browser to Safari.
2. In the integrated terminal, print/click an http://localhost:… (or other http(s)) link.
3. Click the link.

Expected

The link opens in the configured default browser (Safari), the same as shell.openExternal / open <url> would do.

Actual

The link opens in Google Chrome with a debug session attached. Because Safari is not a supported debug target, js-debug appears to fall back to Chrome rather than deferring to the OS default browser.

Evidence that VS Code (js-debug) is the launcher

log stream --predicate 'eventMessage CONTAINS[c] "Google Chrome"' captured at click time:

AUTHREQ_ATTRIBUTION: … requesting={identifier=com.google.Chrome, pid=34892 …},
                     responsible={identifier=com.microsoft.VSCode,
                                  binary_path=…/Visual Studio Code.app/Contents/MacOS/Code} …

Chrome's launch is attributed to VS Code (not the shell, not open). With no other Chrome-launching tool or extension present, the bundled JS debugger's terminal-link handler is the only code path that launches Chrome's binary directly.

Request

For users whose default browser is unsupported by js-debug (Safari), terminal link handling should either:

1. respect the OS default browser (defer to openExternal) when the link is not explicitly being debugged, or
2. make it clearer that the JS debugger is intercepting the click, and document that "debug.javascript.debugByLinkOptions": "off" restores default-browser behavior.

Setting "debug.javascript.debugByLinkOptions": "off" does resolve it, but the default behavior is surprising and hard to attribute to the debugger. In this specific case, I had proceeded from debugging to publishing, and the NPM Login links opened in Chrome which is not configured with the correct passkey.

Start by tracing the integrated-terminal link handler and how it reads debug.javascript.debugByLinkOptions, then reproduce the Safari/default-browser case described in the issue. Done means an unset option respects the OS default browser for non-debug links, or the interception and the existing "off" workaround are clearly documented, with regression coverage for the reported behavior.