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.

[0xGF]

@strange-qwq this is a great breakdown — thanks for verifying both modes empirically and digging up the Chrome 136 change. Implemented in #113:

1. Numeric port keeps the current HTTP discovery flow, and the connect-failure message (plus README/docs) now includes the --user-data-dir requirement you pointed out — the old example silently stopped working on Chrome 136+.
2. Full WebSocket endpoint is now accepted everywhere the port was: --cdp ws://127.0.0.1:9222/devtools/browser/<uuid> on the CLI and boneyardPlugin({ cdp: 'ws://...' }) in the Vite plugin. It's passed straight through to connectOverCDP, so the chrome://inspect toggle mode works with Chrome's consent prompt intact. The README documents pulling the endpoint from <user-data-dir>/DevToolsActivePort.

3 (auto-discovery from a channel/user-data-dir) I've held off on for now — the profile paths vary per OS/channel and the file can go stale across restarts, so I'd rather see how the explicit ws:// form works for people first. If pasting the endpoint proves annoying in practice, discovery is a natural follow-up; a PR for it would be welcome.

Would appreciate you giving the ws:// form a try on your Chrome Dev setup once it ships.

[0xGF]

boneyard-js 1.10.0 is out on npm with the ws:// support: --cdp ws://127.0.0.1:<port>/devtools/browser/<uuid> on the CLI, cdp: 'ws://...' in the Vite plugin, endpoint taken from <user-data-dir>/DevToolsActivePort (release notes, README has the full walkthrough of both modes). Would love to hear if it connects cleanly through the chrome://inspect consent flow on your Chrome Dev setup — happy to close this on your confirmation.