A native dsh plugin that lifts alarm scheduling to the host process: durable alarms under `$DSH_HOME/proactive/`, cold-session resume, silent wake-ups with tombstone folding, quiet hours, daily delivery budgets and two SSE-synced control panels.
DSH integration
Native runtime
Author-claimed
Safety audit
Unaudited
Last verified
2026-11-10
License
Not specified by the author
01What can it help you accomplish?
Let the model schedule its own follow-ups so a task resumes later even after the session cooled down or the browser was closed
Host-level alarms (once / every / cron / file-schedule) that wake the target session, run one turn, and release the handle again
DeepSeek Harness users running long-lived or unattended agents that need to check back in on their own
Keep autonomous wake-ups from spamming the user
`proactive_reclaim` ends a wake silently, folding the whole turn into a ~70B tombstone, plus quiet-hours and daily delivery budgets
Teams that want proactive agents without surprise notifications or polluted long-term context
02How to install into DeepSeek Harness
Prerequisites
- dsh 0.2.0-rc.1 or newer — on older 0.1.x dsh the peer check skips the plugin entirely and it never loads
- A `web` profile (the README installs with `--profile web`)
Installation steps
- 01
Install from npm: `dsh plugin --profile web add dsh-proactive`
$ dsh plugin --profile web add dsh-proactive
- 02
Or from the monorepo sub-directory: `dsh plugin --profile web add github:john-walks-slow/dsh-proactive#path:/packages/dsh-proactive` — pin the commit with `#<sha>&path:/packages/dsh-proactive` and add the package pnpm prints to `allowBuilds` in `~/.dsh/profiles/web/pnpm-workspace.yaml` on the first attempt
$ dsh plugin --profile web add github:john-walks-slow/dsh-proactive#path:/packages/dsh-proactive
Verify the integration
- Open the session’s “主动唤醒” tab or the settings control centre — both are fed live over SSE from `/api/dsh-proactive/events`
- Use the “立即触发” (fire now) button on a new alarm to test a real wake
03DSH integration and capability boundaries
Native host-level dsh plugin: the bundle ships `dsh.bundle.patch`, so the dsh loader mounts `cordis.patch.yml` automatically after `dsh plugin add` — no manual profile edit. It registers host-level tools (`proactive_set`, `proactive_list`, `proactive_update`, `proactive_cancel`, `proactive_update_settings`, `proactive_reclaim`) for every root agent.
Host-level alarm scheduling
`proactive_set` with one of `at` / `after_seconds` / `every_seconds` / `cron` / `schedule_file`, plus jitter, quiet hours and target mode→a durable alarm stored under `$DSH_HOME/proactive/`, restored automatically after a service restart
`every` needs ≥300s and adjacent `cron` triggers need ≥300s`jitter_seconds` adds `uniform(0, jitter)` to each fire time to avoid thundering herdsSilent wake with tombstone folding
a wake turn where the model decides nothing needs reporting→`proactive_reclaim` as the only action — no visible text, the turn folded to a single ~70B tombstone while the human-readable log keeps the full trace
the turn does not consume the daily visible-message budgetFile-schedule handles
`schedule_file` pointing at a single absolute JSON path→child alarms derived from the entries in that file — writing the file adds/updates/removes them, idempotently and surviving restarts
one handle per file; the file is the single source of truth, so deleting it revokes the planatomic writes are a hard contract: write a temp file and rename, never delete-then-createLive control panels over SSE
`/api/dsh-proactive/events` server-sent events→a per-session “主动唤醒” tab (alarm list, history audit, create / pause / resume / edit / fire now) and a host-wide control centre in Settings
global guardrails live here: master switch, daily delivery limit, quiet hours, default prompt
04Who is it for? When not to use it?
Good for
- DeepSeek Harness users running long-lived or unattended agents that need to check back in on their own
- Teams that want proactive agents without surprise notifications or polluted long-term context
Not for
- On dsh 0.1.x the peer check skips this version and the plugin never loads; those deployments must stay on `dsh-proactive@0.2.3`.
- Upgrading from 0.2.x: the old global `config.scheduleFiles` glob is gone. Each schedule file needs its own handle — run `scripts/migrate-schedule-files.mjs` after stopping dsh, or create handles one by one — otherwise those files produce no alarms and leftover `decl_*` alarms are cleaned up as orphans.
- A file handle created without any `target_*` only accepts the convention that the file’s grandparent directory is a registered workspace; otherwise it fails closed and demands an explicit `target_workspace_path` or `target_session_id`.
05Compatibility, maintenance and safety notes
- On dsh 0.1.x the peer check skips this version and the plugin never loads; those deployments must stay on `dsh-proactive@0.2.3`.
- Upgrading from 0.2.x: the old global `config.scheduleFiles` glob is gone. Each schedule file needs its own handle — run `scripts/migrate-schedule-files.mjs` after stopping dsh, or create handles one by one — otherwise those files produce no alarms and leftover `decl_*` alarms are cleaned up as orphans.
- A file handle created without any `target_*` only accepts the convention that the file’s grandparent directory is a registered workspace; otherwise it fails closed and demands an explicit `target_workspace_path` or `target_session_id`.
- The plugin makes no external network requests of its own; the panels use local dsh services under `/api/dsh-proactive/*`, and all writes stay inside `$DSH_HOME/proactive/` except the single JSON path a file handle declares.
README states MIT (facts pack license field is null) · no GitHub release published (facts pack latest_release = null)
06Frequently asked questions
How is this different from a timer started inside a session?
An in-session timer dies with the frontend or session handle. dsh-proactive moves scheduling to the host process, persists data in `$DSH_HOME/proactive/`, wakes the cold session through `resume` when the alarm fires, releases the handle after the turn and heals itself across restarts.
Which dsh versions work?
The current version targets dsh 0.2.0-rc.1 and above. On older 0.1.x dsh the peer check skips the plugin and it never loads — those deployments must use `dsh-proactive@0.2.3`.
Will proactive wakes spam me with notifications?
The model can call `proactive_reclaim` as its only action when there is nothing to report: no visible text, and the whole turn is folded into a single ~70B tombstone in the model-visible context. Quiet hours can skip triggers entirely, and a daily delivery budget caps visible messages.
Do I have to configure the profile after installing?
No. The package ships `dsh.bundle.patch`, so the dsh loader mounts `cordis.patch.yml` automatically after `dsh plugin add`.
What is the file-schedule alarm type?
A handle on one absolute JSON schedule file (`type: "file"`). It never fires itself; it syncs the entries in that file into child alarms, which are ordinary alarms on the same scheduling, budget and retry path.
07Related DSH workflows
archify
by tt-a1i
Turn any idea, plan, or codebase into a beautiful interactive diagram. An agent skill for Claude Code, Codex, and more.
openviking
by volcengine
Self-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.
aitoearn
by yikart
Let's use AI to Earn!
learn-harness-engineering
by walkinglabs
Harness engineering beginner tutorial, from 0 to 1
08Data and sources
安装即生效：包内自带 `dsh.bundle.patch`，dsh loader 自动挂载 `cordis.patch.yml`，无需手工改 profile 配置。
插件为每个 root agent 注册以下 host 级工具（冷唤醒会话与普通日常会话均完全可用）：
This page is generated from the project’s public documentation, repository metadata and a structured parse of DSH Plugins; last verified on 2026-11-10. Found an error? Submit a correction.
Best DeepSeek Harness Plugins
Twelve plugins worth installing first — picked from the whole catalog, across every category.