Preface¶
When writing code in DeepSeek Harness (DSH), many tasks should not be tied to the current conversation. Reviewing local tests on weekday mornings, scanning repository health once a week, and verifying an unstable failure a few hours later—these tasks require a complete, clearly written set of instructions and a run result that can be checked afterward, rather than returning to the same session to continue chatting 10 minutes later.
DSH’s built-in Core Schedule is suitable for reminders like “return to this session to continue checking in 10 minutes.” Another type of demand is different: the task must be independently understandable, each execution must fall within a clear workspace and permission boundary, and records must be left after completion. The community plugin dsh-automation does exactly this: it schedules coding tasks into brand-new root Agents and Sessions instead of continuing to run in old conversations.
This article is organized after cross-checking with the plugin directory page, GitHub repository README / package.json, and the official DeepSeek Harness repository. The directory site is community-curated and has no official affiliation with DeepSeek / Fangtian; you should still review the source code and license before installation.
What Is It¶
dsh-automation is a workflow and automation plugin for DeepSeek Harness, maintained by titanwings, with the repository titanwings/dsh-automation, licensed under MIT, and primarily written in TypeScript. The npm package name is @dsh-external/dsh-automation, and the current version is 0.1.5. The community directory categorizes it under the “Workflow and Automation” category, with an inclusion date of 2026-08-15; the GitHub repository was created on 2026-08-13 and had approximately 45 stars as of 2026-08-17.
The problem it solves can be summed up in one sentence: Save a self-contained coding task, execution plan, and permission boundary, and each time the schedule expires, execute it in a brand-new root Agent and Session, leaving an auditable run history.
Both users and eligible root Agents can create, pause, resume, run immediately, view, and manage these rules. Each actual dispatched occurrence uses the saved prompt, not the conversation history from when the rule was created.
The core philosophy of the official DeepSeek Harness repository is “Everything is a Plugin.” dsh-automation is an independent community plugin implemented based on DSH and Cordis, without patching the DSH Core. The README states that the product model was inspired by Codex Scheduled tasks, especially the distinction between “return to the original conversation” and “start an independent run”; the implementation itself does not copy Codex’s internal code.
Core Features¶
One Control Plane, Two Entry Points¶
After installation, you do not need to run a separate bot, daemon interface, or third-party scheduler. There are two management entry points:
- DSH Web: In the chat interface, next to Chat and Trajectory, there is an “Automation” tab for creating rules, pausing or resuming, running immediately, deleting, and viewing recent runs.
- Eligible Root Agents: Make requests using natural language. The plugin provides six limited-scope tools, and Agents can only manage rules in their current canonical workspace and cannot pass arbitrary paths to cross boundaries.
The six tools and their uses are as follows:
| Tool | Purpose |
|------|---------|
| automation_create | Create an independent rule bound to the current workspace |
| automation_list | Read rules, next occurrence, and recent history |
| automation_update | Modify name, prompt, schedule, permissions, or toggle active/paused status |
| automation_run_now | Queue a manual run with the same boundaries |
| automation_runs | Read a limited number of run histories, errors, summaries, and Session IDs |
| automation_delete | Delete the rule definition while retaining persisted run records |
The plugin will require manual confirmation when an Agent creates or expands future unattended work. Read-only queries and updates that only pause rules will not trigger this step.
Human-Readable Execution Schedules¶
Rules support four schedule types: one-time, fixed interval, daily, and weekly. Daily and weekly schedules use IANA time zones (e.g., Asia/Shanghai); the friendly form in the interface will normalize them into validated RFC 5545 RRULEs for persistence and checking.
There are two notable constraints for interval scheduling: the minimum interval is five minutes; the first run will not occur immediately after creation, but after the full interval has elapsed. Daily/weekly schedules are calculated based on the local HH:mm of the time zone; local times that do not exist during daylight saving transitions will be skipped instead of being shifted to the next minute.
Clean Execution Boundaries Every Time¶
Each actual dispatched occurrence will receive:
- A new Session ID and brand-new root Agent
- The saved prompt, not the history of the source conversation
- The workspace, cwd, Agent preset, model target, and permission preset captured at creation time
- An explicit automation message source with the automation ID, run ID, and scheduled time
- Final results derived from the actual DSH turn end state, rather than treating “message delivered” as success
There are only two permission levels: read-only and workspace-write. Unattended mode does not accept danger-full-access. The approval policy for each new Session is never: tools that still require interactive approval will fail directly instead of waiting indefinitely or silently escalating privileges.
Failures Are As Explainable As Successes¶
A run will go through queued, running, and finally enter succeeded, failed, skipped, or cancelled. Each record will retain the definition revision, prompt and target snapshot, scheduled time, result Session ID, limited-length summary, and structured errors.
Modifying a rule will increment the revision, so historical records still show which version of the definition was executed at the time. Deleting a rule will not immediately erase these run records. The retention policy only cleans up the oldest terminal-state records; records in queued / running status will not be pruned.
Installation and Activation¶
The installation command given on the community directory page is:
dsh plugin add github:titanwings/dsh-automation
The dsh CLI will parse the plugin from GitHub and install it into the current configuration. The directory page also reminds users that for reproducible installations, the commit hash should be pinned:
dsh plugin add github:titanwings/dsh-automation#commit
Replace #commit with the actual reviewed commit SHA.
The recommended method from the repository README is more specific: this plugin includes a Web client and needs to be installed into the DSH Web profile, then restart dsh web. The current reproducible version tag is v0.1.5:
dsh plugin --profile web add github:titanwings/dsh-automation#v0.1.5
If running from the DSH source code directory, replace dsh with pnpm dsh.
When installing from a local checkout, Node.js 22.19 or higher is required:
git clone https://github.com/titanwings/dsh-automation.git
cd dsh-automation
pnpm install
pnpm check
cd /path/to/deepseek-harness
pnpm dsh plugin --profile web add /absolute/path/to/dsh-automation
The repository includes pre-built Host and Web bundles. Installing via Git will not run the package build script, and allowBuilds does not need to be added.
The plugin runs with the permissions of the current dsh process, and may execute code during installation. Please review the source code repository and license before installation.
Typical Usage¶
Creating from DSH Web¶
- Open a Session that is already connected to the target workspace.
- Select “Automation” next to Chat and Trajectory.
- Fill in the independently understandable task, schedule, IANA time zone, and permission boundary.
- Before officially relying on scheduled runs, click “Run Immediately” once first to check the resulting Session and run record.
Letting an Agent Create¶
After installation, eligible root Agents will gain access to the above set of management tools. The example given in the README is:
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.
A high-quality task should clearly state: the goal, evidence to check, allowed modifications, verification methods, and termination conditions. Do not write “continue our previous discussion” or “fix all issues”—scheduled runs will not inherit the conversation context from when they were created.
What Actually Happens During Scheduling and Resumption¶
These semantics come from the repository README. Version 0.1 dispatches on an at-most-once basis, rather than promising exactly-once external side effects:
| Scenario | Behavior |
|---------|----------|
| Overlap | Each rule can have at most one active run at a time; if the scheduled occurrence arrives while the previous run is still queued/running, it will be marked as skipped(overlap) |
| Host delayed restart | Within the default 15-minute grace window, only the latest task will be re-run; old tasks will not be replayed into the write backlog |
| Run timeout | The Agent will be cancelled after the default 60 minutes, and the run will be marked as failed |
| Host crash | Upon recovery, persisted queued / running records will be marked as failed(host_interrupted); no silent re-runs will occur |
| Retries | Only manual “Run Immediately” is supported; there is no automatic retry for side-effecting tasks |
The DSH Host must be running when a task starts. Version 0.1 is not an operating system daemon, and will not coordinate multiple Hosts competing for the same storage directory.
The default configuration in the repository’s cordis.patch.yml is: maxConcurrentRuns is 2 (this is the global capacity of the current Host, and single rules still prohibit overlap), runTimeoutMinutes is 60, misfireGraceMinutes is 15, and historyLimit is 200. To change these values, modify the plugin row in the deployment profile. Increasing concurrency or timeout is equivalent to expanding unattended workloads, and should be treated as a policy decision rather than a pure performance parameter.
Applicable Scenarios and Notes¶
The repository defines “worth scheduling” tasks as repeatable, bounded, and easy to verify. Official examples include:
| Task | Recommended Permission | What It Does |
|------|----------------------|--------------|
| Weekday Regression Triage | read-only | Check local test evidence, categorize failures, and leave diagnostics in a new Session |
| Weekly Repository Health Report | read-only | Review stale TODOs, dependency lists, ignored failures, and test gaps, without modifying the code tree |
| One-Time Delayed Verification | read-only | Recheck a flaky failure later, leaving evidence unrelated to the current conversation |
| Generated Code Refresh | workspace-write | Rebuild clearly scoped generated artifacts, run focused checks, and report accurate diffs |
| Maintenance Fix Window | workspace-write | Reproduce a bounded issue, make a verified minimal fix, and stop after meeting acceptance criteria |
The following categories are currently not suitable for this plugin: tasks depend on unrecorded historical conversations; approval from others is required mid-run; they should be triggered by files, HTTP, process status rather than time; reminder/heartbeat tasks in the same conversation should still use DSH Core Schedule.
Version 0.1 deliberately does not provide: raw cron or arbitrary shell actions, unattended full access, automatic retries for side-effecting tasks, Git worktree creation and cleanup, multi-workspace / DAG / cross-run hidden memory, external email/SMS/push notifications, and exactly-once guarantees for external side effects. Currently, only local execution is implemented.
The security boundaries need to be emphasized separately. The trust scope for unattended coding is smaller than interactive chatting: runs will not inherit the source conversation’s history, inbox, grants, or historical approvals; the fresh Agent only allows a streamlined set of coding tools, and interactive questions, planning, goals, nested Agents, runtime-mounted plugins, terminal/background tasks, recursive automation management, and unknown third-party tools will be rejected; management RPC only accepts loopback connections. These constraints do not automatically sandbox all third-party DSH tools—foreground shell and network behavior still depends on the selected Agent preset, tool set, and DSH guards. Before enabling unattended writes, be sure to use “Run Immediately” to review the actual behavior first.
Finally, the plugin runs with the permissions of the current dsh process. Both the community directory and the repository are open-sourced under the MIT license, and you can freely view the source code before deciding whether to install it; check the repository and license before installation, and pin commits or version tags for reproducible environments.
Summary¶
dsh-automation brings the ability to “run a coding task independently later and leave inspectable results” into DSH’s own Web interface and Agent tools. It does not wake up old conversations, but instead spins up a new root Agent and Session each time, with tightly restricted permissions by default, and run history is retained by revision.
If you are already using DeepSeek Harness and have repeatable, clearly written tasks that can be validated within read-only or workspace-write boundaries, you can install it into the Web profile from the directory page or repository using the commands above, verify once with “Run Immediately”, then enable scheduling.
- Directory Page: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-automation/
- GitHub: https://github.com/titanwings/dsh-automation
- DeepSeek Harness: https://github.com/deepseek-ai/deepseek-harness