{"version":"2.1.280","anchor":"project-thread-resume-now-also-considers-parked-thread-ses","canonical_anchor":"project-thread-resume-now-also-considers-parked-thread-ses","heading":"Remote-control bridge sessions track 'parked' vs 'live' project-thread status","tier":"notice","area":"Sessions","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/project-thread-resume-now-also-considers-parked-thread-ses","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### Remote-control bridge sessions track 'parked' vs 'live' project-thread status\n\nRemote-control bridge sessions now distinguish parked from live project-thread sessions and report more detailed telemetry about them.\n\n**What**\n\n- The bridge loop now distinguishes project-thread-bound sessions more explicitly: session-done telemetry (`tengu_bridge_session_done`) gains a `project_thread` field, session-start telemetry gains `rc_child`\/`project_thread`\/`resumed_turn` fields, and shutdown persistence separately tracks \"parked\" vs \"live\" project-thread session IDs (`parkedProjectThreadSessionIds`) so they can be remembered across restarts.\n\n- Starting a headless bridge session now emits a `tengu_bridge_started` event with `max_sessions`, `sandbox`, `spawn_mode`, `heartbeat_interval_ms`, and `headless` fields, and requeuing project-thread sessions on startup emits a new `tengu_bridge_project_thread_requeue` event with requested\/requeued\/dropped\/deferred\/unattempted counts.\n\n- The function deciding whether to resume a project thread now checks both the live `projectThreadSessionIds` and the new `parkedProjectThreadSessionIds` set (each with its own persisted-at timestamp), resuming if either is populated.\n\n**Why**\n\nThis lets remote-control sessions survive restarts more reliably by remembering project-thread sessions that were parked rather than actively running, and gives clearer telemetry for diagnosing bridge\/session behavior.\n\n- Area: Sessions\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5"}