Introduction¶

In DeepSeek Harness (DSH), two common “deferred execution” needs arise during development: one involves setting a reminder within the current conversation to return to the same session later, while the other requires a complete coding task to run independently at a fixed time or interval, with clear records of the configuration and results each time.

DSH Core Schedule addresses the former. For the latter—executing saved tasks in brand-new root agents and sessions each time, with auditable run records—the community plugin titanwings/dsh-automation (approximately 78 stars on GitHub) offers a dedicated workflow path. Below, we introduce it in the order of installation, configuration, and usage.

What Is This¶

titanwings/dsh-automation is published by maintainer titanwings, categorized as a workflow, currently at version 0.1.7 under the MIT license. This plugin binds “complete task + run plan + permission boundaries” together: users or agents create and manage scheduling rules via DSH Web or conversation; each dispatched occurrence starts in a brand-new session, does not inherit the source conversation’s history, and writes to a persistent run history.

Here is a comparison with DSH Core Schedule:

Tasks that rely on unwritten conversation history, require manual approval midway, or should be triggered by file, HTTP, or process state rather than time are not currently suitable for automation.

Core Features¶

One Control Plane, Two Entry Points¶

DSH Web: Open the control plane from the sidebar or the “Automation” tab in a conversation to create, pause or resume, run immediately, delete rules, and view recent runs. When starting a new, empty conversation page, the sidebar prompts you to begin a conversation first to avoid silent failures.

Qualified Root Agents: Describe your needs in natural language. The plugin provides six scoped tools, and agents can only manage automations within their current workspace, without cross-workspace operations.

There is no need to maintain separate bots, daemon UIs, or third-party schedulers.

Readable Run Schedules¶

Supports one-off, fixed intervals, daily, and weekly schedules. Daily and weekly rules use IANA time zones; form inputs are normalized to validated RFC 5545 RRULE and then persisted. Interval scheduling has a minimum of five minutes, and the first run occurs after a complete interval, not immediately upon creation.

Independent Model Targets¶

The web form can follow the runtime global model or fix a provider/model combination. When fixed, it can use that model’s default effort level or choose a published effort value for that model. Each run’s snapshot preserves the model target as set at creation time.

Agent tools expose the same fields: omitting the model field during creation captures the full selection of the creating session; explicitly setting provider and model to null reads the current global selection at each run time.

Clean Execution Boundaries¶

Each dispatched occurrence receives:

• A new session ID and a fresh root agent;
• The saved prompt, not the source conversation history;
• The workspace, cwd, agent preset, permission preset, and model target captured at creation;
• An automation message source with origin identifier (including automation ID, run ID, and scheduled time);
• Terminal results based on actual DSH turn ends, not just “message delivered.”

Explainable Run History¶

A run progresses through queued, running, and finally enters succeeded, failed, skipped, or cancelled. Each record retains the definition revision, prompt and target snapshots, scheduled time, result session ID, summary, and structured errors. Modifying a definition increments the revision; deleting a definition does not immediately erase run records.

The six agent-side management tools are as follows:

When an agent creates or expands future unattended work, the plugin requires human confirmation; read-only queries and updates that only pause rules do not add this step.

Installation and Enablement¶

The plugin targets the DSH Web profile and requires Node.js 22.19 or higher. The official installation command is:

dsh plugin --profile web add github:titanwings/dsh-automation#v0.1.7

After installation, restart dsh web. If running from the DSH source directory, replace dsh with pnpm dsh. The version tag ensures reproducible deployments; using a reviewed commit SHA is also acceptable.

When installing from a local checkout, first run pnpm install and pnpm check, then use an absolute path: dsh plugin --profile web add /absolute/path/to/dsh-automation. The repository includes pre-built host and web bundles, so no additional build steps are needed for Git installations.

Typical Usage¶

Creating from DSH Web¶

1. Open a session connected to the target workspace.
2. Open “Automation” from the sidebar or select it next to Chat and Trajectory; if starting a new, empty conversation page, begin the conversation first.
3. Fill in the independently understandable task, schedule, IANA time zone, model target, and permission boundary.
4. Before relying on scheduled runs, click “Run Now” to check the result session and run record.

Letting an Agent Create Rules¶

After installation, you can issue a request like this to a root agent:

Create a read-only automation for the current workspace named "Weekday Regression Triage."
Run every weekday at 09:30 in Asia/Shanghai. Check the latest local test evidence,
identify regressions, and return a brief report. Do not modify files.

Use cases listed in the README include: weekday regression triage (read-only), weekly repository health report (read-only), one-off delayed validation (read-only), code refresh generation (workspace-write), and maintenance fix window (workspace-write). A high-quality task should clearly state the goal, evidence source, permitted modification scope, verification method, and stop conditions, avoiding context-dependent phrases like “continue the previous discussion.”

Optional Configuration¶

cordis.patch.yml provides conservative defaults that can be adjusted in the plugin row of the deployment profile:

After setting archiveRunSessions to true, terminal run sessions are archived from the regular list, but the automation run history retains the session ID, summary, and error. The current harness does not yet provide an unarchive API, so archived results only show status and do not offer a session opening entry.

Use Cases and Considerations¶

Who It’s For: Developers who need repeated or one-off, independently articulable coding tasks to run unattended, with each run occurring within a clear workspace and permission boundary and leaving auditable history.

Security Boundaries: Scheduling is not authorization. Runs do not inherit the source conversation’s history, inbox, grants, or historical approvals; rules only support read-only or workspace-write, and do not accept unattended danger-full-access. Each fresh session’s approval policy is never, and tools requiring interactive approval will fail directly. Agent tools are bound to the caller’s canonical workspace, and fresh agents are only allowed a streamlined set of coding tools; the management RPC channel only accepts loopback authority. Before enabling unattended writes,务必 first review actual behavior with “Run Now.”

Run Permissions: The plugin runs with the current dsh process permissions. Before installation, review the source code and MIT license to ensure the task description and permission boundary align with your security expectations.

Current Version Boundaries (0.1): Does not provide in-chat heartbeat, raw cron, unattended full access, automatic retries of side-effectful runs, Git worktree management, multi-workspace targets, external notifications, or exactly-once guarantees for external side effects. The DSH host must be running at task start; version 0.1 is not an operating system daemon and does not coordinate multiple hosts contending for the same storage directory.

Conclusion¶

dsh-automation integrates “scheduled execution of independent coding tasks” into the DSH plugin ecosystem: Web and agents share a single control plane, each run completes in a brand-new session, history is auditable, and boundaries are configurable. The DSH community directory SkillHub (skillhub.cn) has included this plugin entry; complete documentation, design, and issues are available in the GitHub repository titanwings/dsh-automation.