autodsh — Automation Task Plugin for DeepSeek Harness
⚠️ AI Development Notice: This project was developed with AI assistance
(DeepSeek Harness coding agent). Code, comments, and documentation contain
AI-generated content, reviewed by humans and multiple automated review
rounds. The publisher takes responsibility for the final content.
autodsh is an automation-task plugin for DeepSeek Harness.
Users create automation tasks through conversation; each task follows a
three-part architecture — trigger + automation content + result
notification — managed from a unified task panel.
Features
| Capability | Description |
|---|
| Persistence | Tasks and run history persist to $DSH_HOME/storages/autodsh.json (official storage-domain + JSON backend, atomic writes) |
| Lifecycle | The plugin starts/stops with DSH; enabled tasks resume scheduling automatically on startup |
| Triggers | Fixed interval, cron schedule, condition (last status / last duration / time window), parent-child |
| Execution isolation | Each task runs in its own agent session and working directory; child tasks inherit the parent's workspace and run context |
| Run statistics | Run count, total duration/tokens, last run time/status/result, used plugins and skills |
| Notifications | record (log) / email (SMTP, with file attachments) / session (DSH-IM social-software bridge) |
| Permission management | Per-task permission preset: workspace-write or danger-full-access (long-term authorization, no approval prompts) |
| Conversation control | 9 autodsh_* model tools: create/update/delete/list/detail/run/stop/history/settings |
| Auto-learning | Installs the autodsh-control skill so models automatically know how to control the plugin |
| Task panel | Built-in Web panel (list/detail/edit/run/stop/delete/history) with full configuration forms |
Architecture
┌──────────────────────────────────────────────┐
Chat/User ─▶│ autodsh (Host half, resident with DSH) │
│ │
│ autodsh_* tools ←→ task store (storage-domain)│
│ │ ▲ │
│ ▼ │ change events │
│ trigger engine ──▶ task runner │
│ (interval/ (isolated agent session + │
│ cron/ workspace, stats) │
│ condition/ │
│ parent) │ │
│ ▼ │
│ notifier (log / email / IM) │
│ │ │
│ autodsh-control skill (model auto-learning) │
└───────┼──────────────────────────────────────┘
│ /autodsh/api (webServer routes)
┌───────▼──────────────────────────────────────┐
│ Task panel (Client half, Web settings page) │
└──────────────────────────────────────────────┘
See docs/ARCHITECTURE.md for details.
Installation
Requirements: DeepSeek Harness >=0.1.2-rc.1 (dsh 0.1.2 line) with
@deepseek-ai/cordis ^4.0.2. v0.2.0 is not compatible with the 0.1.1
line — see RELEASE_NOTES.md.
Mount name must be the full package name. DSH Desktop 2.0.6 / dsh
0.1.2-rc.1 validate that a loader row's specifier equals the name in the
target directory's package.json. Install this package at
node_modules/@juuuw/autodsh and mount it as name: '@juuuw/autodsh'.
The legacy layout (node_modules/autodsh + name: 'autodsh') now aborts the
whole DSH boot with
dsh-plugin-desktop: profile package identity is invalid for autodsh;
scripts/install-local.mjs migrates it automatically.
Local development install (recommended first)
# 1. Build in the project root
npm install
npm run build
# 2. Install into a target profile (copies artifacts, writes the scoped mount
# row, migrates a legacy unscoped install, backs up the patch)
node scripts/install-local.mjs desktop
# or: node scripts/install-local.mjs web
# 3. Restart DSH
Smoke-test the boot without touching your daily profiles (isolated DSH_HOME):
node scripts/verify-boot.mjs --app "<...>/DSH Desktop.exe"
# prints the plugin's own boot log; passes on "[ready] all ok"
Manual approach (when the install script does not apply):
dsh plugin --profile web add link:<absolute path of this repo>
# Add the mount row to the target profile's cordis.patch.yml:
- insert:
- id: autodsh
name: '@juuuw/autodsh'
Data lives in $DSH_HOME/storages/autodsh.json.
Install from npm (published on npmjs.com)
The package is published to the official npm registry as @juuuw/autodsh.
# 1. Install from the default npm registry
npm install @juuuw/autodsh
# 2. Add the mount row to the target profile's cordis.patch.yml:
# - insert:
# - id: autodsh
# name: '@juuuw/autodsh'
Alternative source: @juuwaii/autodsh is also published on the GitHub
Packages registry (see README.zh.md for registry config).
Quick Start (conversation)
After installing and restarting, just say:
- "Create an automation task that checks my project dependencies every morning at 9 and summarizes"
- "Fetch a news digest every 2 hours and email it to me"
- "Automatically retry once when my inspection task fails"
- "List all tasks" / "Disable task xxx" / "Run task xxx now"
The model auto-loads the autodsh-control skill and uses the autodsh_*
tools. You can also manage tasks in Settings → Autodsh Task Panel.
Task Fields (viewable/editable in the panel)
Name, description, enable toggle, trigger (type and parameters), task content
(prompt), key parameters (sensitive ones masked), working directory, agent
preset, permission preset, run timeout, notification channels/timing,
email recipients, parent task, run statistics (last run time/duration/status/
result, totals, used plugins/skills), and run history.
The panel's Edit Config form supports:
- name / description / task content
- trigger switching (interval interval-ms, or cron expression)
- notification channels (record / email / session) with timing and recipients
- permission preset (default /
workspace-write / danger-full-access)
Permission Management (Long-term Authorization)
Each task can declare a permission preset (permission field, also available
in the panel and autodsh_task_create/update tools):
| Preset | Sandbox | Approval | Use case |
|---|
workspace-write | workspace + allowed temp dirs | ask | Default; wider operations require approval |
danger-full-access | full file access | never | Unattended long-running tasks: full permissions, no approval prompts |
The preset is applied to the task agent at run time via permissionPresets.set
(sandbox mode + approval policy). Unknown preset names only warn and do not
block the run.
Notifications
- record: appends to
<dataRoot>/notifications.log (JSONL); always available.
- email: SMTP mail. Configure
smtp.host/port/secure/user/password/from
via the autodsh_task_settings tool (or settings), and set emailTo on the
task. A zero-dependency SMTP client (node:net/tls) supports 465 direct TLS,
587/25 STARTTLS, AUTH LOGIN/PLAIN, UTF-8 base64 bodies, and file
attachments (multipart/mixed; result files under 10 MB are attached
automatically).
- session: injects the result into the session that created the task.
If that session is bound to a social channel by
DSH-IM (@xmanrui/dsh-im), the result is
delivered with the next interaction (DSH-IM push is message-driven: only
replies of user-message turns are pushed; there is no proactive text API,
and the QQ channel does not implement file messages). For proactive
delivery use the email channel.
Triggers
interval: fixed period in ms (optional random jitter);schedule: 5-field cron (min hour day month dow, local timezone; day/dow
combine with standard cron semantics);condition: last run status / last duration comparison / time window
(fires once per window);parent: triggers the child after the parent run ends, on
success | failure | completion | always (with optional delay), and injects
the parent's result summary into the child prompt.
Development & Testing
npm install
npm run build # Host (tsc) + Client (tsc + rollup)
npm test # unit tests (node --test)
- Test coverage: cron parsing, file storage (atomic updates/capacity/history
cleanup), trigger engine (all four trigger types), notifier, SMTP client
(local fake server, incl. multipart attachments), task-runner full-chain
orchestration, panel API (45 tests).
- Rich code comments; relative imports follow the NodeNext
.js suffix
convention.
Requirements Traceability
See README.zh.md for the full requirement mapping table.
Privacy & Security
- The committed code contains no personal information, secrets, tokens, or
machine paths; local test data lives under
$DSH_HOME and gitignored
directories.
- Task key parameters support the
secret flag: masked as ****** in the
panel and model tools.
- SMTP passwords and other sensitive settings are kept in
$DSH_HOME/settings.yaml (DSH defaults to 0600) and are masked on read.
- Plugin data is plaintext local storage; avoid storing high-value
credentials. Clear sensitive content before sharing/publishing task configs.
License
MIT
