Files
hermes-agent/tools
teknium1 7a55ef4b6b fix(bot-screen): agent attaches to a human-started dock Browser instead of dying on the profile singleton
The dock's Browser launched raw Chromium on the shared user-data-dir with no automation
endpoint. When the human opened it first and handed back, agent-browser's own launch was
forwarded into their instance by Chromium's ProcessSingleton and exited 21 without a
DevToolsActivePort, so every browser_navigate failed until the human closed their window.
The reverse order worked, which is why it slipped through.

- The dock command carries --remote-debugging-port=0, so a human-started instance advertises a
  port in <user-data-dir>/DevToolsActivePort (browser.dock_command; runtime.start reads it).
- browser.running_instance_cdp_port() trusts that file only when SingletonLock's pid is alive
  AND the port accepts a connection (both files outlive a closed Chromium), and never for the
  instance the calling agent-browser session launched itself: handing that daemon --cdp makes
  it treat the launch as a config change, close its browser and attach to the port that just
  died with it (seen live).
- The local argv builder appends --cdp <port> to the --session launch when such an instance
  exists, so the same daemon (and its snapshot refs) drives the human's window.

Live, HERMES_HOME=/tmp/bs-f-home on this host: human-first — dock instance up, navigate x2
succeeded, one Chromium main process (same pid) throughout; agent-first — navigate, dock
click, navigate x2 succeeded, one process throughout. Before the fix human-first returned
"Chrome exited early (exit code: 21) ... Failed to create SingletonLock".

(cherry picked from commit d732fad0af005ffd38eca153dd29c0f7e9dd6bc7)
2026-09-12 18:59:14 -07:00
..