Idea: an optional fresh-session delivery mode for dsh-schedule (one run per firing)

[tigerwho1888]

What exists today. @deepseek-ai/dsh-schedule (0.2.0-rc.1) binds every task to the session that created it. Delivery resolves that stored session and appends a follow-up message to its inbox (lib/types/runtime.js: this.ctx.sessionController.resolveAgent(task.sessionId) → followup(message)), so a firing runs a turn inside a conversation you already have. The README's known limitations list "delivery outside the original Session, and a new Session for each run" as not supported.

Why a fresh-session mode would help. A recurring job then reuses one conversation forever: its history grows with every run (and with compaction-basic not enabled by default, nothing shrinks it), so each run pays to re-read everything before it, and a run that fails halfway leaves its mess in the same thread the next run starts from. Long-running unattended work is exactly the case where a clean context per firing is worth having.

Precedent in the same product category. ChatGPT/Codex scheduled tasks ship both halves — "Schedule a task inside a chat" (reuses that chat's context) and standalone tasks, where "standalone scheduled tasks start a new chat for each scheduled run" (https://learn.chatgpt.com/docs/automations). Claude Code likewise ships the session-scoped /loop alongside desktop and cloud tasks that run with no session open (https://code.claude.com/docs/en/scheduled-tasks). A per-task choice between the two is the norm rather than an exotic ask.

Ask. Consider an optional per-task delivery target, e.g. target: "session" | "new" on schedule_create. With "new", a firing would start a fresh run in the task's configured workspace/preset/model and record its outcome where the Tasks page can show it (and schedule_list/history could link the run's session id), while keeping the parts that already work well: the durable task row, the single host timer, catch-up on the latest missed occurrence, retention, and cancellation semantics.

Prior art. A community plugin already does the fresh-run model with ctx.agents.create() + followup() — @argszero/cordis-plugin-schedule-cron, announced in #5641. The ask here is for the official plugin to carry the same capability, so it inherits the scheduler's durability and management surface instead of living beside it.