[Bug]: /browser connect can report success on Chrome 144+ built-in Remote debugging while CDP tools still fail

Summary

On recent Chrome versions with the built-in chrome://inspect/#remote-debugging UI flow enabled, Hermes can report a successful /browser connect to http://127.0.0.1:9222, but subsequent browser/CDP usage still fails.

This looks like a Hermes-side compatibility regression around CDP endpoint normalization and connection validation.

Why this matters

The docs still present ws://localhost:9222 / /browser connect as the local Chrome flow, and this worked previously. After upgrading Hermes, the same user workflow stopped working.

In Chrome's newer built-in Remote Debugging / DevTools MCP flow:

• port 9222 is open
• DevToolsActivePort is written with a real /devtools/browser/... path
• but traditional discovery endpoints like /json/version and /json/list return 404

Hermes currently appears to rely too heavily on those HTTP discovery endpoints for the shorthand forms (http://127.0.0.1:9222, ws://localhost:9222), and /browser connect can also report success based on an open TCP port even when the endpoint is not actually usable through Hermes' later resolution path.

Environment

• Repo: NousResearch/hermes-agent
• Hermes local checkout upgraded recently (behavior regressed after upgrade)
• Chrome: 147.0.7727.56 on macOS
• OS: macOS
• Repro uses Chrome's built-in chrome://inspect/#remote-debugging toggle, not a custom --remote-debugging-port launch

Reproduction

1. Open Chrome >=144.
2. Go to chrome://inspect/#remote-debugging.
3. Enable Allow remote debugging for this browser instance.
4. Confirm Chrome shows a local server on 127.0.0.1:9222.
5. In Hermes CLI, run:

   /browser connect

   or configure:

   browser:
     cdp_url: "ws://localhost:9222"

6. Observe Hermes reporting success.
7. Then try to actually use browser tools.

Actual behavior

A. /browser connect can say success too early

Hermes prints:

✓ Chrome is already listening on port 9222
🌐 Browser connected to live Chrome via CDP
Endpoint: http://127.0.0.1:9222

But this only proves a TCP listener exists, not that Hermes can actually resolve or use the CDP endpoint.

B. Discovery endpoints return 404

In this Chrome mode:

curl -i http://127.0.0.1:9222/json/version
# -> HTTP/1.1 404 Not Found

curl -i http://127.0.0.1:9222/json/list
# -> HTTP/1.1 404 Not Found

C. Chrome still exposes a real browser websocket

DevToolsActivePort contains a real browser target, for example:

9222
/devtools/browser/d7504e91-bbf6-44f0-9338-46952523ed7c

So a full websocket like:

ws://127.0.0.1:9222/devtools/browser/d7504e91-bbf6-44f0-9338-46952523ed7c

is available even though /json/version returns 404.

Strong evidence this is a Hermes regression / incompatibility

I traced the current implementation locally.

1. Newer Hermes normalizes shorthand CDP URLs through /json/version

tools/browser_tool.py now has _resolve_cdp_override() which rewrites shorthand values like:

• http://host:port
• ws://host:port

into a discovery request against /json/version before returning a concrete websocket URL.

This behavior was introduced in commit:

• bb59057d5df2aca11e65bf9b0031d5ace1155f54
• fix: normalize live Chrome CDP endpoints for browser tools
• date: 2026-03-19

That means ws://localhost:9222 is no longer treated as a simple pass-through shorthand; it depends on classic HTTP discovery succeeding.

2. Chrome's new built-in Remote Debugging UI breaks that assumption

With Chrome's built-in chrome://inspect/#remote-debugging flow, 9222 is open but /json/version is 404, so the shorthand resolution path breaks.

3. Full websocket endpoints still work inside Hermes' resolver

I locally verified that when browser.cdp_url is set to a full websocket endpoint including /devtools/browser/..., Hermes' own resolver accepts it as-is:

• tools.browser_tool._get_cdp_override() -> returns the full websocket unchanged
• tools.browser_tool._resolve_cdp_override(full_ws) -> returns the full websocket unchanged
• tools.browser_cdp_tool._resolve_cdp_endpoint() -> returns the full websocket unchanged

So the problem is not that Hermes cannot use a websocket endpoint at all. The problem is specifically the shorthand/discovery path and the false-positive success messaging in /browser connect.

Expected behavior

At least one of these should happen:

1. /browser connect should not report success unless Hermes can actually resolve and use the endpoint.
2. Hermes should support Chrome's newer built-in Remote Debugging flow more gracefully, for example by:
   • accepting the built-in flow without mandatory /json/version discovery, or
   • probing DevToolsActivePort / equivalent fallback when /json/version is absent, or
   • allowing ws://localhost:9222 shorthand to degrade more intelligently.
3. If the built-in Chrome remote debugging mode is unsupported, Hermes should emit an explicit, actionable error instead of a misleading success message.

Important related Chrome behavior

This is happening in the context of recent Chrome changes:

• Chrome 136+ no longer respects --remote-debugging-port on the default user data directory unless a non-default --user-data-dir is provided.
• Chrome 144+ added the built-in chrome://inspect/#remote-debugging / DevTools MCP flow.

So more users are likely to hit this specific path now.

Proposed fixes

Option A: Improve /browser connect validation

After accepting a URL, validate it the same way later browser tools will actually consume it. Do not mark the browser as connected based only on a listening TCP socket.

Option B: Add fallback for Chrome built-in Remote Debugging mode

If /json/version returns 404 but DevToolsActivePort exists and contains a browser target path, synthesize:

ws://127.0.0.1:<port><browser_path>

and use that.

Option C: Better docs / explicit unsupported-mode message

If chrome://inspect/#remote-debugging is intentionally unsupported for now, surface that clearly in docs and in the CLI output.

Extra UX note

This bug is especially confusing because the CLI can say the browser is connected, and users may assume subsequent browser tool failures are caused by site issues rather than the CDP attach step never having truly succeeded.

Willing to help

I already reproduced this locally and narrowed it down to the shorthand CDP normalization path vs Chrome's newer built-in Remote Debugging mode. If useful, I can test candidate fixes against a Chrome 147/macOS setup.