Schedule reminders keep firing in archived sessions, and never fire in cold ones

[cmsflash]

@deepseek-ai/dsh-schedule ties reminder delivery to whether a root Agent object happens to be resident in the process. That runtime-residency condition doesn't line up with what a user thinks "this conversation is active" means, and it produces two opposite surprises.

Archived sessions still fire. WorkspaceApi.archiveSession calls ctx.workspaceRegistry.archiveSession(sessionId) and returns the updated id set — that's the whole handler. It never touches ctx.agents, and nothing disposes the agent. The client mirrors this: archiving the current session only clears the selection (workspaces-service.client.spec.ts, "Archiving the current session clears it into the New Session view state"). So a session you archived stays resident and its ScheduleRuntime timers stay armed. A reminder can start a turn in a conversation the user deliberately put away — and it won't be in the sidebar to explain where it came from.

Cold sessions never fire. ScheduleRuntime installs on agent/created, so timers exist only while an agent is resident. ensureSession mints agents only on a request for that identity, and history reads go through the detached path (persistence.inspect()), which creates no agent. A session nobody opened this run is cold: its reminder sits overdue until someone opens that conversation, even with dsh web up the whole time.

These are the same root cause. Residency is an implementation detail of the agent runtime; Schedule inherited it as a delivery condition, and archive state was never crossed with it.

I don't think deliveryMode: 'session-local' is wrong as a v1 boundary — the conversational-delivery note is explicit that external delivery "requires a different product boundary." But the archive interaction reads like an unconsidered crossing rather than a deliberate limit. Two things that would help independent of any larger scheduler work:

1. Decide the archive crossing explicitly — either archiving disposes the agent (stopping its timers), or archived records are skipped at the dispatch decision, or it's documented as intentional.
2. Say plainly in the README that "live" means an agent is resident, not the process is running and not the session is unarchived. The current "must be live" phrasing reads like uptime.

Happy to send a PR for whichever direction maintainers prefer.

[nokkies]

Confirmed the archived half against our own tree, with a root cause one layer below where the report places it, and fixed it there.

You attribute it to WorkspaceApi.archiveSession never touching ctx.agents. That is the visible symptom, but the handler could not retire the agent even if it tried: ctx.agents.create() / .resume() return an AgentHandle whose dispose() is the only teardown capability — ctx.agents.get() deliberately yields a bare Agent — and the gateway takes .agent from both call sites, dropping the handle. In our tree grep -rn "\.dispose()" packages/host/*/src/*.ts found no agent disposal anywhere in the host packages. So no session could be retired by any code path in a running dsh web; agents were resident for the process lifetime.

That has a second consequence beyond schedules, which is how we noticed independently: a delete API that refuses while a session is live becomes unsatisfiable, because nothing can stop being live. Archive succeeded, delete refused, and only restarting the host got through.

Our fix keeps each handle keyed by session and retires the agent in archiveSession after the archive is durable. Disposal stops the loop, awaits its exit, and unregisters the agent, so every per-agent runtime armed against it — schedule timers included — goes with it. No schedule-specific code was needed, which is the part worth stealing: the reminder-in-an-archived-session symptom is a residency bug, not a scheduling bug.

Two notes for anyone implementing it upstream:

• Ordering matters: retire after durability, so a disposal that fails cannot leave the session unarchived. We warn and continue rather than failing the archive.
• Our test harness hid the bug and would hide the fix: its stub agent factory's dispose only unregistered the agent and left the session in the store, while the liveness check reads the session store. The suite therefore reported every retired session as still live, and an existing assertion was describing the stub rather than production. Worth checking whether the same is true of yours before trusting a green run.

We are not taking the cold-session half. ScheduleRuntime installing on agent/created means a reminder for a session nobody opened this run cannot fire, and fixing that properly needs schedules to live outside agent residency — a design change rather than a fix, and one with a real question attached: something must decide who pays for waking a cold session, and how a user learns that a conversation they never opened started talking.

One behaviour change we accepted deliberately, since your report implies it: archiving a session with a turn in flight now stops that turn.

[argszero]

Verified the residency analysis against upstream rc.2 (not a fork), and it holds at every layer. This deserves to be more than a schedule fix — it's the missing retirement primitive for the whole session-lifecycle family.

Source confirmation, claim by claim:

• Zero .dispose() calls in packages/host/*/src/*.ts — grep comes back empty on the upstream tree, exactly as you found in yours.
• AgentHandle is the only teardown capability: core/agent/src/index.ts:159-164 documents the disposer as "a CAPABILITY" — dispose() stops the loop, awaits its exit, unregisters the agent. createAgent/resume return the handle (:202, :223), while ctx.agents.get() deliberately yields a bare Agent (:167).
• The archiveSession handler (host/apiproxy/src/api/workspace.ts:107) forwards to workspaceRegistry.archiveSession and never touches ctx.agents — the reported symptom is exact at the handler level.

The cross-link to the delete design is direct. In #4441 we are designing a sessions.delete that refuses live sessions — and your "nothing can stop being live" consequence is the reason that refusal is unsatisfiable without this fix. A delete API with a live-refusal guard is only implementable once a retirement path exists, and your archiveSession-retire is the first such path in the product. The sequencing insight (retire after durability, warn-and-continue on disposal failure) is exactly the ordering the delete path will need for its own storage-first commit.

One test-harness pattern worth generalizing. Your stub's dispose unregistered the agent but left the session in the store, while the liveness check reads the session store — so the suite reported retired sessions as live. That stub-divergence class (test double mutating less than production, so assertions describe the stub) is easy to reintroduce in any retirement feature; a shared invariant test that pins "after dispose: agents.get returns undefined AND liveness reads false" would have caught it on both sides.

The cold-session half staying out of scope is the right call — schedules outside agent residency is a delivery-boundary decision, not a fix. But the archived half now has an independent upstream verification, and the delete design in #4441 has its missing precondition identified.

[nokkies]

Thanks for verifying it against upstream rather than taking the fork's word — and your stub-divergence point is the most useful thing in this thread, so I took it.

On the shared invariant. Agreed that "after dispose: agents.get returns undefined AND liveness reads false" is the right shape, and worth stating why it bites so hard here specifically: the two halves are read by different subsystems. The retirement path acts on the agent registry, while the delete guard reads the session store, so a double that mutates one and not the other produces a suite where every assertion is individually true and the composite claim is false. That is not a stub being lazy; it is a stub encoding a coupling the production factory owns and the test never restates. Any retirement feature reintroduces it.

One refinement from doing it. The invariant wants to be an assertion helper the harness exposes rather than a test in one package, because the divergence appears wherever a fake factory does. Ours now goes through prepare + enter and calls the returned detach in dispose, which is the smallest way to make a double honour the real contract instead of re-implementing it — the store hands back the removal, so a fake cannot forget what production remembers.

On the sequencing generalizing to delete. Yes, and the ordering has a second reason beyond symmetry with storage-first commit: retiring before durability would make a failed archive leave the session stopped, which is worse than a successful archive leaving it briefly running. Whichever step is irreversible for the user should be the one that has already succeeded when the other is attempted. For delete that means storage first, registry second; for archive it means durable archive first, retirement second.

I would add one caveat to "the missing retirement primitive for the whole family": archive-retire is a retirement trigger, not the primitive. The primitive is holding the handle at all, and anything else wanting to retire — an idle-eviction policy, a memory-pressure reaper, an explicit close verb — needs the same retained handle and will want its own trigger. If upstream takes this, the handle map is the part worth landing first and separately; the archive call site is one line on top of it.