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)
7a55ef4b6b