Introduction¶

The built-in “Automated Tasks” in DSH trigger by time: daily, weekly, cron, or fixed intervals. In actual use, more common needs are “triggered by what happened”: the host started, a session began or became idle, a user sent a message, or a tool execution finished—built-in capabilities do not cover these moments.

dsh-automations is the plugin used to fill this gap. It is maintained by 439436269-ctrl, aimed at DeepSeek Harness, and categorized as a “Workflow”. The plugin adds an “Lifecycle Automation” (labeled “Automations” in the English interface) entry in the sidebar; opening it shows the rule management page: you can create rules, start/stop them, run them immediately, and view recent run outputs; the same batch of rules can also be read/written by the model via tools.

Below is an introduction to its triggers, actions, panel, model tools, and methods for installation and verification.

Triggers¶

The plugin provides nine types of triggers, covering time and events:

A few tested semantic details: a user message generates multiple user/message events (the message body plus context), the plugin deduplicates by turn, so a message triggers only once; daily will run once after startup if the window is missed (the window is 4 hours), earlier misses will not be compensated; interval timing starts when the rule is first seen, persisted in meta.json, and continues after restart; session-end also triggers when DSH exits normally, at which point actions might not have time to write to disk, so avoid long commands here; the “once” for startup is counted by process, HMR reload will not repeat execution.

Actions¶

Actions are divided into three types, covering local commands, network requests, and debug logging:

Note that an empty cwd for shell actions equals defaultCwd (default user home directory). Shell gets a set of environment variables, scripts can reference them directly:

DSH_AUTOMATION_RULE_ID     Rule ID
DSH_AUTOMATION_RULE_NAME   Rule Name
DSH_AUTOMATION_TRIGGER     Trigger Type
DSH_AUTOMATION_SESSION_ID  Session at trigger (may be empty)
DSH_AUTOMATION_TOOL        Tool name at trigger (tool-after)
DSH_AUTOMATION_CONTEXT     One-line JSON (kind/sessionId/tool/source/at)

Panel¶

Clicking the icon in the left column enters the main area page, divided into a statistics bar and two tabs: “Rules / Runs”. The Rules tab uses rule cards to manage start/stop, run, edit, and delete. When the panel is empty, it offers three templates: startup logging, daily 08:30 health check, and session idle recording. The Runs tab is the full run history (Time / Rule / Trigger Type / Status / Duration), clicking a row expands the output, and the expanded header includes the trigger and exit code. Tab selection is stored in localStorage, and refreshing stops on the previous tab.

“New Rule” dynamically generates the form using the same catalog: after selecting a trigger, only relevant fields appear; the same applies for changing actions; the working directory for shell rules is pre-filled with the default path. “Test Run” can execute once without saving, convenient for debugging commands. The interface text follows DSH’s language (Chinese / English).

Tools for the Model¶

The plugin registers five tools, allowing the model to directly read/write rules:

A short description was added to the system prompt, so when users say “Start X every time DSH starts” or “Remind me at 8:30 daily”, the model will create a rule instead of manually executing it every time.

Storage and Configuration¶

Rules and scheduling state fall into the local directory:

$DSH_HOME/storages/dsh-automations/
  rules.json   Rules (atomic write, saves as .broken-<ts> on corruption and starts from empty)
  runs.json    Recent runs (limit maxRunHistory)
  meta.json    Scheduling memory: which daily have run today, interval last time, recent user message date

The stateDir config item can be changed entirely elsewhere. The config items in cordis.patch.yml are as follows:

- id: dsh-automations
  name: dsh-automations
  config:
    enabled: true
    stateDir: ""              # empty = $DSH_HOME/storages/dsh-automations
    maxRunHistory: 200
    maxOutputChars: 8000
    defaultTimeoutMs: 120000
    defaultCwd: ""            # default working directory for shell rules; empty = user home directory
    startupDelayMs: 2000
    tickSeconds: 15
    promptEnabled: true
    promptOrder: 62

The patch is a full replacement for config; to change one key, you must write the keys you want to keep together.

Installation and Activation¶

Install from npm; the README gives:

# Install from npm (recommended)
node "<dsh>/lib/bin.js" plugin --profile <profile> add dsh-automations

Where <dsh> refers to the installation directory of @deepseek-ai/dsh (its lib/bin.js). After installation, add dsh-automations to the dsh.profile.bundles in that profile’s package.json, then restart the host or let the plugin manager hot load. During development, you can link directly to the source code directory; changes take effect after restarting the host:

node "<dsh>/lib/bin.js" plugin --profile <profile> add "link:D:\path\to\dsh-automations"

The desktop version is completed via the “Install” button on the plugin page, equivalent to the pnpm command above.

Typical Usage¶

The examples in the README all follow the logic of “Trigger + Action + Log” and can be reproduced directly:

1. Configure startup trigger with log action to verify if the rule hits after the host starts.
2. Set daily trigger at 08:30, configure http action for health checks, verify time triggers.
3. Configure session-idle trigger with log action to record session idle.

When debugging commands, use “Test Run” in the panel to execute once without saving to confirm it works before saving. If you want to start a service when a message first arrives, set the mode of user-message to first-of-session, use shell action, and cwd pointing to the project directory.

The self-test commands in the repository cover model normalization, storage, engine, and trigger wiring, totaling 12 items:

cd dsh-automations
node test/selftest.mjs

For real device verification, start Web with a temp profile using --no-open --port 0, use the ?token= from the output to replace cookie and call /api/dsh-automations/state; then confirm the sidebar entry and rule editor; finally, create a new session and send a message, checking the run records for session-start, user-message, tool-after, and session-idle.

Use Cases and Notes¶

Suitable for developers who need to run deterministic actions at DSH lifecycle and event nodes: starting services after boot, recording on message arrival, reporting after tool execution, or scheduled health checks or notifications. Event triggers can be more precise than time triggers; implementing this type of requirement with built-in scheduled tasks often requires instrumentation or polling.

A few points to note:

1. Shell actions execute arbitrary commands with the current user’s permissions. The rule file is at $DSH_HOME/storages/dsh-automations/, and the panel API uses the host’s authenticated /api channel. Since the people who can modify rules can already execute commands on this machine, please treat it like ~/.bashrc.
2. The plugin currently does not have an action to “send a prompt to the agent”, it only performs deterministic actions like commands, HTTP, and logs. For scheduled tasks requiring agent participation, still use DSH’s built-in schedule tool or panel.
3. Commands execute serially at the same time (queue limit 200) to avoid two rules moving the same file or port at the same time.
4. Rules are modified by the panel or tools; directly editing rules.json manually requires a host restart to be read.
5. Regarding compatibility, the README records that DSH 0.2.0-rc.2 and 0.2.1-rc.3 have been tested successfully; the host relies on peerDependencies for compatibility; Node requires >=22.
6. It is recommended to check the source code and license before installation; this plugin is under the MIT License.

Conclusion¶

The value of dsh-automations lies in extending automation from the timeline to the event axis, and providing the same set of rule read/write methods via the panel and model tools, suitable for scenarios where DSH lifecycle nodes are incorporated into automation orchestration. The directory page and source code are located at:

• Directory Page: https://www.skillhub.cn/plugins/439436269-ctrl/dsh-automations
• GitHub: https://github.com/439436269-ctrl/dsh-automations

It should be noted that the aforementioned community directory is an independent site with no official affiliation to DeepSeek / Hypothesis.