browser session idle time too short. 5 minutes ? Make it longer or user configurable #456

Activity

1. legend91019 commented on Oct 18, 2026

   

   legend91019

   on Oct 18, 2026

   Contributor

   More actions

   I would like to take this issue.

   Proposed Plan

   1. Support \BSK_SESSION_IDLE\ and \BSK_DAEMON_IDLE\ environment variables on \StartArgs\ (\crates/bsk-cli/src/cli/daemon.rs), allowing users and agent runners to configure the session idle timeout and daemon idle timeout without modifying command flags.
   2. In \ensure_daemon()\ (\crates/bsk-cli/src/cli/ensure_daemon.rs), ensure auto-spawned daemons also pick up and pass down \BSK_SESSION_IDLE\ and \BSK_DAEMON_IDLE\ so background instances respect environment configuration.
   3. In \�pply_start_args()\ and \StartArgs::resolved_session_idle()\ /
      esolved_daemon_idle(), ensure environment fallbacks are consistently resolved.
   4. Add unit and CLI tests in \crates/bsk-cli/tests/cli_parse.rs\ verifying env-based and flag-based resolution.
   5. Document \BSK_SESSION_IDLE\ and \BSK_DAEMON_IDLE\ in \crates/bsk-cli/skill/references/environment.md.
2. DaqiHu commented on Oct 29, 2026

   

   DaqiHu

   on Oct 29, 2026

   More actions

   Another data point for a configurable idle timeout (CLI and extension 0.3.3, Windows 11, Edge 156).

   Several agents share one browser through separate sessions. One agent's session was stopped by the reaper while its task was still running:

   {"level":"INFO","fields":{"message":"idle session stopped","session":"<id>"},"target":"bsk::daemon::start"}
   

   The agent had made no bsk request for five minutes while it recorded results and decided whether to retry an earlier download. It had unresolved state in that session's tabs, and the stop discarded it.

   The only control today is bsk daemon start --session-idle <DURATION> (DEFAULT_SESSION_IDLE in crates/bsk-cli/src/cli/daemon.rs). On a shared daemon, raising it means restarting the daemon and interrupting every other session's work. Options that would avoid that, any one of them:

   • a per-session idle setting at bsk session start, for example --idle 30m;
   • an environment variable or config file read by the auto-started daemon;
   • an explicit bsk session keepalive / touch command, so long non-browser steps can hold their session without issuing dummy page commands.

   😄React with 😄1Reacted by chriscentrumhl-sketch
3. legend91019 commented on Oct 30, 2026

   

   legend91019

   on Oct 30, 2026

   Contributor

   More actions

   Thanks for the concrete data point — the multi-agent shared-browser scenario, and especially the lost tab state after idle session stopped, makes the case for this much stronger.

   PR #463 implements option (b). It adds BSK_SESSION_IDLE and BSK_DAEMON_IDLE environment variables, picked up both by explicit bsk daemon start / restart and by auto-spawned daemons (ensure_daemon() propagates them), with CLI flags still taking precedence. So a runner can set e.g. BSK_SESSION_IDLE=30m in its environment instead of editing DEFAULT_SESSION_IDLE or restarting the daemon by hand just to pass --session-idle.

   Limits relative to your other two options — both of which I agree are the better long-term shape, and both left out of #463 to keep it reviewable:

   • (a) per-session --idle at bsk session start — would let one long task stretch without raising the ceiling for every sibling session on a shared daemon. Env vars are process-wide, so feat(daemon): support BSK_SESSION_IDLE and BSK_DAEMON_IDLE environment variables #463 does not solve the "shared daemon, uneven session lengths" case cleanly.
   • (c) bsk session keepalive / touch — the cleanest fix for your exact scenario (long non-browser step holding an open session). With it, a recording/retry-decision step could hold the session explicitly and the idle timeout could stay short for genuinely abandoned sessions.

   Both (a) and (c) would make good follow-ups once #463 lands; I'd rather not fold them into that PR and make it harder to review.

   #463 has been open since 2026-10-18 with CI green and no review feedback yet — a look would be welcome.