Startup session recovery: auto-resume of sessions interrupted by app closure — shipped as a plugin

[tmttodd]

Startup session recovery: auto-resume of sessions interrupted by app closure — shipped as a plugin

TL;DR — The desktop host has quit-time inspection of active work but no startup recovery path: after any closure (crash, SIGTERM, deliberate quit/reload), interrupted sessions stay interrupted until a human notices. We shipped a plugin that closes the gap, verified against a real closure-then-relaunch cycle, and are sharing it as a reference implementation: tmt-homelab/dsh-session-auto-resume (topic dsh-plugin).

What it does at boot

• Sessions whose durable goal snapshot is phase active are explicitly resumed (agents.resume + goals.resume) — the goal-round-driver then continues the round budget automatically. (The driver intentionally "never revives work on its own"; the plugin performs the explicit resume the driver requires, under a one-time policy the operator opts into by installing the plugin.)
• Mid-turn sessions without a goal are detected and logged with a ready-to-run resume command — surfaced, never auto-worked.
• Cleanly-ended, stale (>48 h), live, and subagent-owned sessions are skipped; per-boot resume cap; fail-closed on goal transitions; never-throw activation. It never hand-appends to session logs (the headerSeq append contract makes cold-log markers unsafe).

How it was verified

A real closure-then-relaunch (operator-approved SIGTERM of the running host; app relaunched):

• An unscripted interrupted goal session — not planted, unknown to the operator — was auto-resumed and re-armed at boot, and its round continued.
• A session holding an active goal continued on an automatic continuation round with no human message.
• Budgets advanced correctly; a live session was correctly skipped; 489 subagent-owned sessions were correctly excluded in one pass.

verify-d1.mjs (included) turns any future closure into a one-command verdict (PASS/FAIL/VOID with the failing check + evidence tail), and its own fixture selftest exercises every verdict path against synthetic evidence trees.

One vendor-relevant bug found during the live fire

Resuming a session programmatically without agentOptions produces an agent whose turns fail with prompt variable "{{model}}" has no value — the agent loop binds {{model}}/{{provider}} from agent.options (dsh-agent-loop), and a bare agents.resume({resumeSessionId}) leaves them unbound. Reproducer: agents.resume({resumeSessionId}) on a persisted session, then send a message. Suggested improvements: bind a default (or the session's recorded model/selection) when agentOptions is omitted, and/or fail the resume with a precise error instead of failing every later turn with a template error. (Filed separately below.)

Feedback welcome

We'd love to know whether a first-class startup-recovery hook (a workspace/session-recovery surface the host calls at boot, or a documented resume recipe) is on the roadmap — happy to contribute design notes. Related filing: the host-process observability gap is tracked in #10022.