fuhefei/dsh-sentinel

Condition-driven wakeup for DeepSeek Harness: durable file/command/http/process/webhook watches that wake the

dsh-sentinel is a condition-driven wakeup plugin for DeepSeek Harness: the agent registers a watch, goes to sleep — even closes the session — and the sentinel wakes it when the condition happens. Six sensors: file (path snapshot + inotify push, fires sub-second on change), command (read-only shell line on an interval), http (URL status/body change), process (pgrep -f match-set change), port (TCP reachability change), and webhook (pure push to a returned hook URL). Every subscription and fire is a user-visible session event; the browser dock above the composer lists active watches with live probe state, fire budget, and next-probe countdown; a sidebar branch shows a count per session and a standalone dashboard tables every watch server-wide. Subscriptions survive process restarts via a plugin-owned sidecar log ($DSH_HOME/sentinel.jsonl), late-firing conditions that became true while the server was down. Delivery is at-least-once with a delivered watermark. An optional notifyWebhookUrl fans every fire out as JSON to a Lark/WeCom/Slack bot.

Web UI Enhancements ★ 11 updated 2026-09-12 ⏳ pending
View on GitHub ↗

Install

dsh plugin --profile web add dsh-sentinel

One line through the official bundle channel — dsh plugin --profile web add dsh-sentinel — or from git with dsh plugin --profile web add "github:fuhefei/dsh-sentinel#v0.11.0" (build artifacts are committed, so the git-source install runs no build). The browser half ships in the same package (./client) and is injected by the Web UI plugin loader. An optional sidebar branch requires applying the bundled session-row-holes.patch to a DSH source checkout and rebuilding ui-workspace.

Compatibility

DeepSeek Harness Web (long-running dsh web process). Watching is a resident-process concern: probing and fire delivery only run while a long-running dsh process is up; headless one-shot runs can create/list/cancel watches but nothing probes after the process exits. One duty owner per $DSH_HOME via a lease file (dsh-sentinel.lease); a second process on the same home stays passive and takes over within one lease TTL of the owner dying.

Details

Recent updates

The current README documents the watch/sensor model, the six sensor engines with pattern matching, configuration schema (heartbeatMs, probeConcurrency, maxSubscriptionsPerSession, dutyLeaseTtlMs, notifyWebhookUrl), the sidebar-branch prerequisite patch, optional better-sidebar integration, and the dsh-notification pairing.

FAQ

Can watches fire while dsh is closed?
No — probing only runs while a long-running dsh process (typically dsh web) is up; conditions that become true while the server is down late-fire on the next probe, because subscriptions persist in a sidecar log.
Do multiple dsh processes double-probe?
No — one duty owner per $DSH_HOME holds a lease file; a second process stays passive and takes over within one lease TTL if the owner dies.
Which sensors are available?
file, command, http, process, port, and webhook (pure push); with pattern, probe kinds fire on the no-match→match regex edge and webhooks accept only matching payloads.

Alternatives

omdsh-dev/dsh-notification · omdsh-dev/dsh_workflow · fuhefei/dsh-sentinel

More plugins in Web UI Enhancements

Browse more in Web UI Enhancements

Guides for Web UI Enhancements plugins