fix(tools): reuse supervisor sessions for browser_cdp target_id

[LeonSGP43]

Summary

• reuse the live browser supervisor session when browser_cdp is called with a target_id that already belongs to the connected supervisor
• track the top-level page target id in CDPSupervisor and resolve target ids back to live session ids before falling back to the legacy stateless attach flow
• add a regression test covering browser_cdp(target_id=...) against the supervisor-backed path

Closes #32685.

Verification

• uv run --frozen --extra dev pytest tests/tools/test_browser_cdp_tool.py tests/tools/test_browser_supervisor.py -q
• source /Users/leongong/Desktop/LeonProjects/worktrees/hermes-agent/.base/.venv/bin/activate && ruff check tools/browser_cdp_tool.py tools/browser_supervisor.py tests/tools/test_browser_supervisor.py
• git diff --check

[teknium1]

Thanks for tackling the persistent-CDP-session path. The reported stateless behavior still exists on current main: browser_cdp opens a per-call WebSocket at tools/browser_cdp_tool.py:206 and target attachment is performed on that same connection at :217-260.

Problems

• The new target_id return precedes the shared private-page guard at tools/browser_cdp_tool.py:484-490. Commit 47764f19f462c0b3a99865255f3b1dfae5098e74 fixed the same early-return bypass for frame_id; the target route needs that guard too.
• #32685's documented Target.getTargets → target-ID workflow is not covered. The new route only runs after a target ID is provided, but the new test reads private sv._page_target_id. SupervisorSnapshot has no top-level target field (tools/browser_supervisor.py:255-279), and browser_snapshot exposes only snapshot.to_dict() (tools/browser_tool.py:2998-3007).
• The new success payload should redact its result like the stateless payload does at tools/browser_cdp_tool.py:524-527.

Suggested changes

• Preserve validation and run _browser_cdp_private_guard before target routing; add the corresponding private-page regression test.
• Provide and test a public supervisor-backed target-discovery path, then use its returned target ID in the E2E test.
• Update website/docs/user-guide/features/browser.md:549, which currently says each non-frame_id call is stateless.

Automated hermes-sweeper review.

[teknium1]

This early return is before current main's shared validation and _browser_cdp_private_guard (tools/browser_cdp_tool.py:448-490). A resolved supervisor target can therefore invoke a raw CDP read on a private current page, recreating the bypass fixed for frame_id in 47764f19. Run the shared guard before this route and add an equivalent target-ID private-page regression test.

[chrisyoung2005]

Verification from a production browserless deployment (Fedora 43, rootless podman, hermes v0.19.0, self-hosted browserless v2 / Chrome 149, tokenless BROWSER_CDP_URL=http://browserless:3000): the approach here fixes #32685's stateless-target failure for pure-CDP workflows — with target ids resolved against the live supervisor session, Target.getTargets → Page.navigate(target_id) → Runtime.evaluate(target_id) chains become self-consistent, which they are not on main today (each call currently lands in a freshly-spawned browserless browser).

One edge case worth handling (or at least documenting) before merge: under browserless, the supervisor's websocket owns a different browser than the agent-browser CLI daemon that browser_navigate/browser_snapshot/browser_click drive — browserless spawns a private browser per connection, so the two paths can never see each other's pages. With this PR, a mixed workflow (browser_navigate, then browser_cdp(target_id=...) using a supervisor-resolved target) resolves to a live, persistent target — in a browser that never saw the navigation. Callers get coherent-looking but empty results instead of today's hard failure, which is arguably harder to debug. We hit exactly this shape via the browser_console supervisor fast path: document.title returned "" while the snapshot showed the fully-loaded page, and the agent misdiagnosed it as target-site bot detection.

A cheap guard would be: if the daemon-driven page's targetId does not appear in the supervisor's Target.getTargets, emit a warning in the tool result (split-brain browser detected) rather than silently serving supervisor-side state as canonical. Happy to test a revision against our deployment.

[chrisyoung2005]

@LeonSGP43 — this fix matters for every Browserless/BaaS deployment (we run one in production, verification above), and it'd be a shame to lose it to the conflict backlog: the branch is now ~2 months behind main (mergeable_state: dirty) and teknium1's July 13 review has three concrete asks outstanding (private-page guard on the target_id return path, public-API coverage of the Target.getTargets workflow instead of the sv._page_target_id test, redaction on the success payload).

If you're still on it — great, happy to re-verify a revision against our deployment. If you're unavailable, I'll re-file this rebased onto current main with the review feedback applied as a salvage PR (crediting this one, per house convention) early next week so the mechanism doesn't stall. Just say the word either way.

[chrisyoung2005]

Salvage PR is up as promised: #71743 — rebased onto current main with the July 13 review feedback applied (guard before target routing + regression test, public page_target_id discovery on SupervisorSnapshot instead of the private-attr test, redaction on the supervisor payload, browser.md update). Credit retained in the commit/PR. @LeonSGP43 if you come back to this, happy to hand it over or fold in anything I missed.