dsh-update-notifier

English | 中文

Hourly — or on demand, with /check-updates — check for newer versions of your
installed DeepSeek Harness
(dsh) plugins, with a one-click approval bubble to upgrade them.

Nothing in dsh tells you a plugin you installed has moved on; you find out by
remembering to run npm view yourself. This plugin closes that gap: it compares
every installed plugin against the registry once an hour and, when something is
newer, asks you — in the session, as a real question bubble — which ones to
upgrade. Tick the ones you want and the agent runs the upgrade in front of you.
It never upgrades anything on its own.

Behavior

Once an hour (configurable), for every npm package backing a loaded plugin:

• Look up the registry's latest and compare it with the version installed
  in your profile's node_modules. Comparison is semver-proper — prereleases
  ordered correctly, downgrades never suggested — and a version that isn't a
  strict X.Y.Z is skipped rather than guessed at.
• Ask, in one bubble. Anything newer becomes a multi-select question
  rendered by dsh itself (dsh-chrome 0.1.2 -> 0.1.3, one option per plugin),
  attached to your most recently active session. It costs no model turn and no
  tokens, and it is replayed if you reconnect.

• Hand the ticked ones to the agent, as a follow-up message telling it to
  run

  pnpm --dir <profileDir> add <pkg>@<latest> ...

  The agent wakes immediately and you watch the upgrade happen. Pair this with
  dsh-hot-reload and the new
  version applies live, without restarting dsh.

/check-updates

Don't want to wait for the hour to come round? Type /check-updates in the
session:

/check-updates
check-updates · 2 updates — see the question above (7 plugins checked)

It runs a full cycle immediately, against the session you typed it in, and the
row settles as soon as the registry sweep finishes — the bubble it raises is an
ordinary one, answerable whenever, surviving a refresh. Where no bubble can be
shown at all, the settlement carries the pnpm ... add command instead, so the
answer is never just "you can't".

Packages the registry could not be reached about — a network failure, a timeout,
a 5xx, a rate-limit, or an answer with no version in it — are counted in the
settlement rather than passed off as up to date, and a sweep where nothing
could be reached settles as an error, not as "no updates". The two counts add up:
5 plugins checked, 2 unreachable means seven were swept. Cancelling the row stops the sweep, so a check you cancel cannot
pop a bubble at you a minute later.

The manual check ignores the decline memory below: you asked, so you get the
full list, including versions you left unticked earlier. It does not disturb the
hourly schedule, and it declines to run — with a reason — while a bubble is
already open or a check is already in flight.

The command appears wherever dsh composes a command registry — which
@deepseek-ai/dsh-base does, so any profile built on it has /check-updates.
It is registered through ctx.inject, so a headless profile without one still
loads the plugin and keeps its hourly checks.

Asked once

You are asked about a given version once (by the hourly cycle — the command
above overrides this):

• Unticked ones are declines, recorded in
  <profileDir>/.dsh-update-notifier.json and never offered again — across
  restarts — until the registry's latest changes to some other version that
  still beats what you have installed. Delete that file to be asked afresh.
• Approvals are not recorded: a successful upgrade makes that version
  current anyway, and one that failed is worth re-offering after a restart.
• A bubble you never answered (session ended, dsh stopped) is not a
  decline — you will be asked again.

With no live session yet, the offer is held: it is retried right after your next
message and on the next hourly cycle. It is also held where nothing can render
the bubble at all — a headless profile, or one that composes the userQuestions
service with no UI registered against it — and there the available updates and
the exact upgrade command go to the log as well, because no message of yours is
going to make a bubble appear.

Install

dsh plugin --profile web add dsh-update-notifier

Then restart dsh once (bundle patch layers load at boot). Works in any
profile — swap web for whichever profile you use; it checks the profile it
is loaded into. Needs Node 18+, for global fetch; any dsh host has it.

Compatibility

Built and tested against dsh 0.1.0-rc.6 (Node 22 / 24). It uses only
public host services, so it degrades rather than breaks if one is absent:

userQuestions and commands are resolved when needed rather than declared as
dependencies, so the plugin still loads in a headless profile that has neither.

Opting out

A plugin that does not want to be offered for upgrade can say so in its own
package.json:

{ "dsh": { "updateNotifier": false } }

Use exclude (below) to silence a plugin you do not control.

Configuration

Set on the update-notifier row in your profile's cordis.patch.yml:

Security

• Nothing is upgraded without your click. This plugin never spawns a package
  manager. It composes the bubble and, on approval, the instruction the agent
  then executes in plain sight.
• No registry prose reaches the UI or the model. Only the package name, read
  from your own profile, and a version string that passes
  /^[0-9A-Za-z.+-]{1,64}$/ are ever put into the bubble or the agent message —
  never a description, README, or changelog fetched from the registry.
• The follow-up message carries source.kind: "plugin", names exactly the
  approved packages, and tells the agent not to touch anything else.

Limitations — read this

• It asks; it does not verify. Once you approve, the upgrade is the agent's
  to run. A failure is visible in the session, but this plugin neither retries
  it nor checks afterwards that the new version is really installed.
• Only registry-installed plugins are seen. A plugin linked from a local
  checkout, or built into dsh, has no package under the profile's
  node_modules and is skipped silently — no bubble, no log line.
• Only the latest dist-tag is consulted. There is no support for pinned
  ranges, next/beta channels, or holding a package back at a major version;
  a plugin whose newest release you never want should use exclude.
• One bubble at a time. While a bubble waits for an answer the hourly checks
  skip — and /check-updates refuses with "an upgrade question is already open"
  — so anything published meanwhile is picked up on the first cycle after you
  answer.
• A decline is keyed to that exact version, not to "anything up to it": if
  the registry's latest moves to a different version that still beats yours —
  including a lower one after an unpublish — you are asked again.
• The bubble needs a session that dsh can attach a question to. Registry
  failures, degraded loader state, and an unwritable state file all degrade to
  logging; only two things disable the plugin outright — no plugin loader on the
  context, and a profile dir it cannot locate — and it says which in the log.

License

MIT © Stuart Hu