[Bug] A session is reclaimed mid-use and the borrowed tab's page state is lost, with no warning #386

Activity

1. lmliheng commented on Oct 1, 2026

   

   lmliheng

   on Oct 1, 2026

   Author

   More actions

   Second occurrence, and this one rules the daemon out as the cause.

   • Session dyrr was healthy and in active use at 22:35 local time; the next
     bsk session list --json at 22:52 returned [].
   • At that exact moment bsk status --json reported:
     • daemon still running: pid 223012, uptime_secs 7182 (~2 h),
     • browser still connected: browsers[0] = edge 154.0.0.0,
       instance_id be16dfae.
   • So the daemon had not idle-exited and Edge had not disconnected. Only the session
     disappeared, after roughly 17 minutes in which no command was issued against it.
   • Same consequence as before: the Agent Window tab is gone, and the state of the
     page it had borrowed is gone with it.

   This makes the "daemon idle exit (#337)" explanation insufficient for this case —
   the reclaiming is happening at the session layer while both the daemon and the
   browser connection are alive. The part that still hurts is that neither the loss
   nor its cause is observable: every other command keeps succeeding, and the caller
   only finds out at the next bsk session list.

   If it helps to reproduce: Windows 11 + Edge, bsk 0.3.2 built from source, the
   borrowed tab sitting on an ordinary https page (a Moka application form), idle for
   ~15-20 minutes with the Agent Window left open in the background.
2. lmliheng commented on Oct 1, 2026

   

   lmliheng

   on Oct 1, 2026

   Author

   More actions

   Correction to my comment above — the daemon log does record why a session ended,
   and I attributed the second occurrence to the wrong cause. I should have read
   bsk logs before writing.

   I now have the daemon's own log (timestamps UTC; local = UTC+8):

   idle session stopped                        session=cpgi   12:04:06Z
   idle session stopped                        session=tvkd   12:48:20Z
   idle session stopped                        session=gffx   13:01:39Z
   idle session stopped                        session=dxzs   13:26:09Z
   idle session stopped                        session=yokv   14:05:40Z   <- the 45-minute loss
   session removed: user closed Agent Window   session=dyrr   14:34:38Z   <- the "second occurrence"
   daemon exceeded idle threshold; exiting     idle_secs=600  17:11:58Z
   

   Two corrections:

   1. The cause is observable. It is in the daemon log, with a distinct message
      per cause. idle session stopped is a session-level idle timeout — separate
      from the daemon's own 600 s idle exit — and cpgi, tvkd, gffx, dxzs and
      yokv all ended that way. My claim that "the reason is not observable either"
      was wrong.
   2. The second occurrence I reported was not the tool reclaiming a session in
      use. For session dyrr the daemon logged
      session removed: user closed Agent Window — the Agent Window was closed, so
      that is not a bug. What I actually observed at the time (daemon alive, Edge
      connected, session list empty) was equally consistent with both causes, and I
      drew the wrong conclusion from it. I withdraw that part of the comment.

   What still stands, and is why this issue is open: sessions cpgi, tvkd, gffx,
   dxzs and yokv were stopped by the idle timeout while the browser was still
   connected and without anything telling the caller beforehand, and the state of
   the borrowed page went with them — for yokv that was roughly 45 minutes of work
   on a form that keeps no server-side draft.

   So the gap is not "the reason is unrecorded". It is that the reason is recorded
   where the caller does not look, and cannot be seen before it happens:

   • bsk session list exposes no lifetime or last-activity, so nothing tells a
     caller that a session is on a clock;
   • the daemon logs the stop, but the next bsk command only says
     session not registered or already stopped — it does not carry the reason that
     the log already has;
   • there is no way to keep a session alive across a long non-browser step.

   The feature request is unchanged, just better aimed: surface the existing
   idle-stop reason and the remaining lifetime at the session layer, instead of
   leaving them in the log file. If the answer is "the log is the interface", then
   bsk session list / the failure error should point at it — that alone would have
   saved me from filing the wrong half of this report.
3. XY-code1 commented on Oct 16, 2026

   

   XY-code1

   on Oct 16, 2026

   More actions

   Hi, I’m interested in working on this issue. I noticed that #456 appears to describe the same session idle-time problem.

   I’d like to start with a minimal, backward-compatible scope:

   • make the session idle timeout configurable;
   • expose the configured timeout and last activity in session status/list output;
   • preserve the current default unless maintainers prefer a new one;
   • add regression tests for expiry and activity-based renewal;
   • update the related documentation.

   Before implementation, could you confirm whether this direction matches the intended session lifecycle design, and whether configuration should be global or per-session?
4. XY-code1 commented on Oct 16, 2026

   

   XY-code1

   on Oct 16, 2026

   More actions

   Hi! I investigated the current implementation and would like to contribute a focused fix.

   I confirmed that the daemon already supports a global --session-idle timeout, but session activity is currently refreshed only by accepted/completed BrowserSkill tool calls. Manual interaction in the borrowed browser tab does not refresh the session, so an actively edited form can still be reclaimed after the timeout.

   I see two possible directions:

   1. refresh the session lifetime from explicit browser/user activity; or
   2. keep the current lifetime semantics, but surface the timeout/remaining lifetime clearly and provide a warning or explicit keepalive mechanism.

   To keep the change backward-compatible, which direction would you prefer? If manual browser activity should count, I can prepare a small implementation with regression coverage. If not, I can focus on lifecycle visibility/documentation and tests around the existing --session-idle configuration.