How to update DSH plugins: the dsh plugin update command

Updating a DSH plugin takes one command: dsh plugin --profile <name> update <pkg>—with a package name it updates one, without a name it updates every plugin in that profile, and a restart of dsh web applies the change (source). This guide answers only "which command do I type to update plugins", across three directions: the command and its order, single versus batch wording, and how to roll back on failure.

Overview: a DSH plugin update command cheat sheet—decide what you are updating

Before anything, ask whether you are updating the app or a plugin—the two tracks use completely different commands.

The key fact: everything after dsh plugin --profile <name> is forwarded straight to pnpm, so verbs like update, add, remove, and why work directly (source).

DSH plugin command and order: check, update, then restart

The order trips people up more than the command, so follow these three steps.

1. See what can be upgraded — in the target profile run dsh plugin --profile web outdated to list packages with newer versions. Expected: a comparison of current versus available versions. If you prefer no CLI, the "update available" badge in the marketplace shows the same thing.
2. Run the update — update <pkg> for one, a bare update for all. Expected: pnpm fetches and writes, updating the profile's package.json and its dependencies.
3. Restart to apply — updates are not hot-reloaded, so restart dsh web to pick up the new build (source). Expected: the plugin version shows the new number after restart.

The graphical path follows the same three steps: in the installed list of DSH Plugin Hub, click "update available" and confirm the dialog to overwrite in place, and the UI flags a pending restart. The marketplace button and the CLI command act on the same layer, just through different entry points.

Single vs batch DSH plugin updates: the wording gap and profile ownership

The two forms differ by one package-name argument, yet their risk surface is entirely different.

• Single update: dsh plugin --profile web update dsh-memory—touches only the named package, leaving other dependencies alone. Suits upgrading one plugin without worrying about knock-on regressions. Steps: Update a single dsh plugin.
• Batch update: dsh plugin --profile web update—bumps every dependency in the profile to its latest allowed version. Suits a periodic sweep, at the cost of more changed packages and a wider surface to debug. Steps: Batch update plugins.

Two preconditions are easy to miss:

1. Target the right profile: plugins belong to a profile, so --profile must name the one your UI runs; the wrong profile changes nothing. For multiple environments, see Update plugins per profile.
2. Separate app from plugin: update -g upgrades the program, dsh plugin ... update upgrades plugins, and the two are independent, so do not mix them up.

When a DSH plugin update fails: pin and reinstall a version

The fastest way back from a failed or broken update is to reinstall the exact version.

1. Retry and localize — first check for a network or mirror problem and retry once; dsh plugin ... outdated tells you which package is stuck. Expected: network-style failures pass on retry.
2. Reinstall a specific version — use dsh plugin --profile <name> add <pkg>@<version> to land on the target version, which rewrites both the profile's package.json and its dependencies. Expected: the plugin returns to the version you named.
3. Pin long term — if a version must stay fixed and never be carried off by a batch update, handle it as a version pin. See Pin a plugin version and Update rollback.

Notes on updating DSH plugins

1. Always restart afterward: without a dsh web restart the new build does not load, so do not mistake "not effective" for a failed update.
2. Record versions before a batch update: it makes problems comparable and lets add <pkg>@<version> roll back precisely.
3. Do not misname the profile: --profile must point at the environment you are running, or the change lands elsewhere.
4. Do not mix the commands: upgrade the app with npm update -g, plugins with dsh plugin ... update—two tracks, each its own.
5. Pin deliberately: a batch update will carry dependencies up within their range, so any package that must stay put has to be pinned explicitly.

Sources: dsh CLI README, DeepSeek Harness source - CLI arg definitions, pnpm docs - pnpm update