Closed bug report

Closing one session force-kills the shared adom-you Chrome while other live sessions still use it (bridge lost track of them)

John Lauer · 8d ago ·closed by John Lauer

What happened (twice in ~5 min, Windows laptop AdomLapper, bridge current as of 2026-08-02): my thread opened session cowboy-wiki (later cowboy-order) in the shared adom-you profile and was actively driving it (browser_eval calls visible in the log between the kill lines). A different thread's session ralph-reap (owner dash-ralph, reason 'ralph: reconciler reap') called browser_close_window on its own session. The bridge then logged: 'No more sessions using profile "adom-you" — killing browser' followed by 'Force-killed Chrome PID 41700 for profile adom-you' — but my session WAS still using that profile and was actively receiving verbs ([verb] browser_eval session=cowboy-order appears immediately before and after the force-kill in the log). My session then returned session_not_found; browser_rescan found nothing to adopt (liveSessions: [ralph-reap] only, later []). Expected: the refcount of sessions-per-profile should include every live session, and a force-kill should never fire while another session in that profile is receiving verbs; or if the bridge lost my session record (a restart?), rescan should re-adopt the still-open window rather than the kill path treating the profile as unused. Impact: my in-progress web flow (typed form state on order.cowboychicken.com) was destroyed twice; I had to move to a private profile ({profile:"cowboy"}) to make progress, which defeats the shared-credential goal. Log excerpt: '[verb] browser_close_window session=ralph-reap' -> 'No more sessions using profile "adom-you" — killing browser' -> 'Force-killed Chrome PID 41700' with '[verb] browser_eval session=cowboy-order' interleaved around it. OS: Windows.

1 Reply

John Lauer · 4d ago

Fixed in bridge 1.9.335. browser_close_window no longer trusts the drift-prone per-profile refCount to authorize the kill. It now decides from ground truth: at close time it counts live sessions still bound to the profile (the closing session is already removed) plus any verb in flight on that profile, and only force-kills the shared Chrome when both are zero. So closing session A can never kill the Chrome that live session B is actively driving. _lostBrowser records intentionally veto the kill (rescan may re-adopt the still-open window).

Not covered: a session record fully removed by a bridge restart (not just _lostBrowser) isn't visible to an in-memory count. Flagging rather than adding an on-disk session-file scan, which could permanently block a legit kill via a stale file.

Log in to reply.