whyihaveyou/dsh-suite#plugin-notify
IM webhook and local notifications on turn completion, errors, or approval (Feishu/WeCom/DingTalk/Slack/Discord/custom).
Install
This plugin lives in a subdirectory of a larger repository, and `dsh plugin add` cannot reach it — it forwards to pnpm, which reads everything after `#` as a git branch or commit. Clone the repository and add the plugin through DSH's plugin panel using a repository source, or ask the author to publish it to npm.
Due diligence
What it is — Sends notifications via IM webhooks and local systems when turns complete, errors occur, or approvals are pending.
Who it is for — When using DeepSeek Harness for turn completion, errors, or approval notifications, users needing instant results should install this plugin. If not involving external IM integration, users can skip this plugin.
Watch out — This is a subdirectory plugin with no single command install. Manual allowance of shell script execution is required from source builds. It executes shell commands and requires API key or token. No sandbox testing was conducted.
The verdict — I would install it because it handles notifications for turn completion and errors in agent workflows, but only if external IM integration is necessary.
Generated by grok-4.6, and a starting point rather than a verdict. Where it says a plugin installs or does not, that is from a real run in a clean profile — everything else is read off the repository. Trust the source over this.
plugin-notify is a DeepSeek Harness plugin that sends notifications when a turn completes, an error occurs, or an approval is pending. It can deliver these notifications through IM webhooks for Feishu, WeCom, DingTalk, Slack, Discord, or a custom destination, and can also produce local system notifications.
The available description identifies the notification events and delivery types, but does not document the implementation details: no hook name, command, configuration key, file path, payload format, or default is provided in the available README. DeepSeek Harness users should therefore treat the repository source as the reference for wiring and deployment rather than assuming a particular configuration interface.
plugin-notify is intended for users who need turn-state alerts outside the DeepSeek Harness interface, especially when approval or failure events must reach an external messaging service. It is the wrong choice when local notifications or existing DeepSeek Harness UI feedback are sufficient, or when the required messaging service cannot accept webhooks. The catalogue flags a terminal surface and a credential requirement. Those flags indicate that installation should be reviewed for terminal access and that configured notification destinations may require credentials; the README excerpt does not specify the exact terminal operations or credential names. No one-line installation command is listed for this plugin.
The available README describes plugin-notify as a notification plugin for three event conditions: turn completion, errors, and pending approval. It does not provide a command reference, configuration schema, payload specification, or destination setup procedure.
The documented delivery options are:
| Destination | Mechanism |
|---|---|
| Feishu | IM webhook |
| WeCom | IM webhook |
| DingTalk | IM webhook |
| Slack | IM webhook |
| Discord | IM webhook |
| Custom destination | IM webhook |
| Local system | Local notification |
The README does not define separate commands or configuration keys for these destinations. It also does not state whether all destinations use the same payload, how a custom webhook is shaped, or how local notifications are enabled.
The catalogue marks plugin-notify as requiring credentials and as having a terminal surface. The available README does not name the credentials, describe their storage, or explain which terminal operations the plugin performs. These details should be checked in the repository before granting the plugin access to an agent profile.
DeepSeek Harness users should also note that no one-line installation command is listed for plugin-notify. The available source establishes the notification scope and delivery categories only; it does not establish a minimum DeepSeek Harness version, supported operating systems, default settings, retry behaviour, or failure handling.
Written from the project's own documentation and kept in sync with it. Where the two disagree, the source is authoritative — read the README on GitHub
Same category
shaobeichen
Remote phone access to the DSH Web UI: scan a QR code for LAN or public (cloudflared tunnel) access with real-time sync, a mobile-adaptive layout, and a settings tab.
Installed cleanly when we ran it
omdsh-dev
Desktop notifications for turn completions, with per-outcome controls and keyword rules.
Installed cleanly when we ran it
omdsh-dev
Open DSH workspace directories in VS Code directly from the web GUI.
Did not install when we ran it
xmanrui
Connect IM bots to DeepSeek Harness by scanning QR codes (supports Feishu, Weixin, DingTalk, and more).
Installed cleanly when we ran it
THEWOLFWALKER
Unified notification & remote control for DSH: one `notify()` API, 25+ channels (Telegram / DingTalk / Feishu / WeCom / QQ bot / WxPusher / PushPlus / ServerChan / Bark / Discord / Slack / ntfy / webhook...), level routing (timeSensitive / active / passive) with tiered retry, multi-channel inbound approval (Telegram buttons, Feishu cards, QQ, WxPusher, WeChat iLink), official QR login for QQ/DingTalk/Feishu, a local web admin console, multi-agent routing, desktop notifications — and a mobile command center: `!status` / `!stop` / `!retry` agent control from your phone plus actionable notifications (view result / retry / logs buttons that call back into the agent). Secrets redacted, tool rate-limited, zero runtime deps — plus an open event source: other plugins can inject the notifier service (ctx.notifier) and subscribe to dsh-notifier/sent events, reusing notification without coupling.
Installed cleanly when we ran it
omdsh-dev
Lark/Feishu bot channel for DeepSeek Harness: each chat drives its own agent, and tool approvals, model questions, and plan reviews return as cards answered by a button or a reply. Switch workspace and model from the chat (`/cd`, `/model`, `/new`), and run several bots that keep separate sessions and can hand turns to each other in one group.
Installed cleanly when we ran it
