[Bugfix] Fix local Chrome CDP attach validation

[HiddenPuppy]

Summary

• fall back to DevToolsActivePort when local Chrome exposes a debug port but /json/version is unavailable
• make /browser connect validate the resolved CDP endpoint before reporting success
• store the resolved websocket endpoint so later browser/CDP tools use the same concrete URL

Root cause

Recent Chrome built-in remote debugging flows can leave port 9222 open and write a real browser websocket to DevToolsActivePort while returning 404 from classic discovery endpoints like /json/version. Hermes treated a listening port as success and relied too heavily on /json/version, so /browser connect could report success even though later CDP usage still failed.

Validation

• source .venv-ci/bin/activate && python -m pytest tests/tools/test_browser_cdp_override.py tests/tools/test_browser_cdp_tool.py tests/tools/test_browser_cloud_fallback.py tests/cli/test_cli_browser_connect.py -q
  • 40 passed
• source .venv-ci/bin/activate && python -m pytest tests/ -q -n 0
  • interrupted after surfacing unrelated pre-existing failures in tests/gateway/*, tests/hermes_cli/test_gateway_wsl.py, tests/hermes_cli/test_gemini_provider.py, and tests/run_agent/test_*interrupt*

[HiddenPuppy]

Hi Hermes team @teknium1 , I’ve really enjoyed following the project and working with the codebase, and I’d love to become a contributor. I’m interested in helping with bug fixes, testing, documentation, and small feature improvements, and I’m happy to start with issues that are most useful to the project. I’d like to contribute consistently, learn the project’s standards, and gradually take on more responsibility over time.☺

[alt-glitch]

Likely duplicate of #12198 — both harden local Chrome CDP discovery to handle /json/version unavailability and validate actual CDP endpoint.

[teknium1]

Thanks for investigating the Chrome built-in remote-debugging path. The underlying compatibility gap remains on current main: tools/browser_tool.py:422–433 returns the raw shorthand after discovery fails, and the CLI rejects the connection at hermes_cli/cli_commands_mixin.py:1847 and :1882–:1886 before it can attach.

Problems

• tools/browser_tool.py:269 on this PR reads parsed.port outside the exception handler. For an invalid port, urllib.parse raises ValueError, changing a failed CDP discovery into an uncaught resolver failure.
• The patch does not cover the TUI browser.manage path, which independently probes only /json/version and /json in tui_gateway/server.py:13707–:13708.
• The second commit includes unrelated run_agent.py, tools/approval.py, model-catalog, and release-map changes. These should not travel with a CDP attach fix.

Suggested changes

• Salvage the fallback into the current shared CLI/TUI connection flow, with tests for 404 + DevToolsActivePort on both surfaces.
• Guard invalid parsed.port access and add the regression test.
• Keep the browser fix scoped to browser files/tests.

This is an automated hermes-sweeper review.

[teknium1]

parsed.port can raise ValueError for a malformed port (for example, http://127.0.0.1:abc), but it is outside the surrounding try. Please catch that case and return the normal empty fallback so an invalid configured endpoint cannot turn discovery failure into an uncaught exception.

[teknium1]

This stale-timeout change is unrelated to local Chrome CDP discovery. Please split it from this browser-focused PR so the CDP fix can be evaluated and salvaged independently.