CDP connection fails with HTTP 404 when using Chrome remote debugging

[strange-qwq]

After enabling remote debugging in Chrome (chrome://inspect/#remote-debugging and toggling “Allow remote debugging for this browser instance”), and configuring vite.config.ts with:

boneyardPlugin({
    cdp: 9222,
    framework: "react",
})

Running the project and visiting any page throws an error in the console:

[boneyard] ✗  capture failed: browserType.connectOverCDP: Unexpected status 404 when connecting to http://localhost:9222/json/version/.
This does not look like a DevTools server, try connecting via ws://.
Call log:
  - <ws preparing> retrieving websocket url from http://localhost:9222

According to Chrome blog, only ws:// protocol appears to work. Suggest boneyard support connecting via WebSocket endpoint or fix the CDP connection logic.

Version info:

• OS: macOS 26.5 (25F71)
• Chrome: 150.0.7838.0 (dev) (arm64)
• Framework: Vite + React
• Vite version: npm:rolldown-vite@7.2.2
• boneyard-js version: 1.8.1

[0xGF]

This one is Chrome-side rather than a boneyard bug. The chrome://inspect → "Allow remote debugging for this browser instance" toggle does not open the CDP HTTP endpoint on port 9222 — so http://localhost:9222/json/version 404s, which is exactly what Playwright's connectOverCDP reports. That endpoint only exists when Chrome is launched with the --remote-debugging-port flag:

# fully quit Chrome first, then:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

Then cdp: 9222 connects fine. (Playwright uses the HTTP endpoint to discover the ws:// URL, so connecting via ws:// directly wouldn't have helped here — the HTTP endpoint simply wasn't being exposed.)

I've documented this properly in #101 (new "Reusing an existing browser" section), including this exact 404 troubleshooting note. Give the --remote-debugging-port launch a try and let me know if it connects.

[strange-qwq]

Thanks for the clarification. I did some additional testing, and I think it would be useful to distinguish the two remote-debugging modes and support both of them in boneyard.

First, the command-line example needs one additional argument on current Chrome versions. Since Chrome 136, --remote-debugging-port is ignored when Chrome uses its default user data directory. It must be combined with a non-default --user-data-dir, for example:

# Fully quit Chrome first, then start an isolated debugging profile:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/chrome-debug-profile

With this mode, http://127.0.0.1:9222/json/version is available, so the existing cdp: 9222 behavior works. Chrome documents the Chrome 136 change here: https://developer.chrome.com/blog/remote-debugging-port

The chrome://inspect/#remote-debugging toggle is a different connection mode available in Chrome 144+ for connecting to an already-running browser/profile. It does not expose the HTTP discovery endpoints: /json/version and /json/list return 404. However, it does expose a usable CDP WebSocket endpoint after the user grants the connection request. Chrome describes this consent-based flow here: https://developer.chrome.com/blog/chrome-devtools-mcp-debug-your-browser-session

Chrome writes the endpoint information to DevToolsActivePort in the active channel's user data directory. The file contains two lines:

9222
/devtools/browser/<random-uuid>

The client can construct the complete endpoint from those values:

ws://127.0.0.1:9222/devtools/browser/<random-uuid>

I verified this on macOS with Chrome Dev 152 using only the chrome://inspect/#remote-debugging toggle. The HTTP discovery endpoints returned 404, while connecting directly to the WebSocket endpoint succeeded for both Browser.getVersion and Target.getTargets, including access to the tabs in the existing profile.

Playwright's chromium.connectOverCDP() accepts either an HTTP URL or a full CDP WebSocket endpoint, so direct WebSocket support should work without changing the underlying Playwright API: https://playwright.dev/docs/api/class-browsertype#browser-type-connect-over-cdp

Would you consider extending boneyard's CDP configuration to support this toggle-based mode? For example, it could:

1. Keep accepting a numeric port for the current HTTP discovery flow.
2. Accept a full ws://.../devtools/browser/... endpoint.
3. Optionally discover the endpoint from DevToolsActivePort when given a Chrome channel or user data directory.

In short, the two modes have different behavior:

Mode	Profile	Discovery/connection	User interaction
--remote-debugging-port + --user-data-dir	Separate non-default profile	HTTP /json/version, followed by WebSocket	No per-connection confirmation
chrome://inspect/#remote-debugging	Existing/default profile	Full WebSocket endpoint from DevToolsActivePort; HTTP discovery returns 404	Chrome asks the user to approve the incoming debugging connection

Supporting the second mode would let boneyard reuse a developer's existing signed-in browser session while preserving Chrome's explicit-consent flow.