dsh-cron

LIMITATIONS

Known limitations

- Agent runs carry a fixed `[CRON RUN]` framing that states the run is unattended and questions are forbidden. It is injected as a scoped system-prompt section, so the user message holds only the job's prompt; hosts without the system-prompt service fall back to prepending it to the message. - Config jobs come from plugin config (declarative); the conversational tools (`cron_list` / `cron_runs` / `cron_run_now` / `cron_enable` / `cron_disable`) observe and steer them but never create or delete them. Runtime "manual" jobs are the exception: `cron_create` / `cron_delete` manage those from a session, guided by the bundled `cron-create` skill (registered into the host's skill registry when one exists), through the same `manual`-table overlay as the web dialog. - Plugin-registered jobs (`source: "plugin"`) are owned by their provider package: they can be run, paused and inspected, but not edited or deleted from the overlay or a session — that is what installing and uninstalling the provider is for. Unmounting a provider leaves an orphan row holding the job's history until the user deletes it. - `queue` depth is 1: only the single latest squeezed-out occurrence is kept. - A run's Session is a plain durable Session (the `dsh-headless` shape), so its conversation stays openable after the run settles. A conversation that is on screen at that exact moment returns to the workspace, and the run row reopens the persisted transcript (the client re-pulls the host session list once when the id is no longer listed). Run Sessions persisted by earlier versions still carry the `origin: "subagent"` header and stay unopenable. - Because a run's Session is plain, the host no longer refuses prompts to it: opening a run while it is still going and typing into it adds a user turn to the unattended run (that turn can surface in the run's summary), and the run's settle then returns that conversation to the workspace. - Run Sessions are no longer hidden from the workspace sidebar (it hides only `origin: "subagent"` Sessions), so every run — live or settled — is listed there; a high-frequency job accumulates entries, and a settled run can be resumed from the sidebar without the `[CRON RUN]` framing.