Update DSH plugins per profile in DeepSeek Harness

dsh plugin updates are per profile: each profile keeps its own package.json and node_modules under $DSH_HOME/profiles/<name>, and dsh plugin --profile <name> update affects only the environment you name, leaving other profiles' plugin versions untouched (source).

"Update every environment at once" is a common misconception: DeepSeek Harness has no global cross-profile plugin update entry point. For the plugin boundaries between the desktop app and the CLI, see DeepSeek Harness desktop vs CLI updates; to choose which version to land on, see update DSH plugins to a specific version. This article is about doing the per-profile update and verifying it.

Why DSH plugin updates are split per profile

A profile is DeepSeek Harness's unit of isolation: each profile has its own package.json and node_modules, so where a plugin is installed and at which version belongs to that profile alone (source).

Start with the profiles and who owns them:

Five facts make separate updates necessary:

1. Dependency directories are independent — each profile's dependencies live under $DSH_HOME/profiles/<name>. Expect to see the plugin lists for web, headless or a custom profile separately.
2. Versions may differ — the same plugin can be a different version in each profile. Expect to trial a new version in one profile without affecting other environments.
3. No global entry point — there is no single command that updates across all profiles. Expect to run one update per environment you care about.
4. Isolation rests on directory boundaries, not command manners — each profile's dependencies sit in a physically separate node_modules. Expect two independent copies even when the same plugin is at the same version, so changing one never moves the other.
5. Verify isolation with a read-only command — run ls -l "$DSH_HOME/profiles". Expect one directory per environment that never overwrites another.

How to update DSH plugins per profile

The syntax names the environment with --profile after dsh plugin, updating a single plugin or every dependency in that profile; doing one profile at a time makes verification easier (source).

Follow six steps:

1. See what can update in the target profile — dsh plugin --profile web outdated. Expect the updatable plugins in that profile.
2. Update a single plugin — dsh plugin --profile web update dsh-memory. Expect only that plugin in the web profile to move.
3. Update every dependency in that profile — dsh plugin --profile web update (no package name). Expect all dependencies in web to update, with other profiles untouched.
4. Repeat for another profile — swap --profile web for --profile headless or your custom profile name. Expect each environment to finish independently.
5. Confirm the profile directory exists first — run ls -l "$DSH_HOME/profiles" (use dir on Windows). Expect your target name among the existing environments instead of a typo landing on one you did not mean.
6. Verify each profile before moving to the next — run list after every profile you update. Expect a problem to surface in the environment that caused it instead of spreading.

One boundary matters for desktop: the desktop profile is held exclusively by the app and the CLI may not start or modify it, so desktop plugins update inside the app (source).

Confirming only the target profile changed

Compare by running outdated or list for each profile involved: a version that moved in the target and stayed put elsewhere proves isolation held (source).

Verify in five steps:

1. Check the target profile — dsh plugin --profile web list to confirm the plugin is now the new version. Expect a version number matching your intent.
2. Check another profile — dsh plugin --profile headless list for the same plugin. Expect it to keep the old version if it was not updated, showing nothing was dragged along.
3. Read the profile directory if needed — open the two profiles' package.json. Expect each to record its own range and version, confirming isolation.
4. Look at the directories with a read-only command — run ls -l "$DSH_HOME/profiles/web" and ls -l "$DSH_HOME/profiles/headless". Expect each to hold its own node_modules, physically two dependency sets.
5. Compare the two package.json files — run cat "$DSH_HOME/profiles/web/package.json" and cat "$DSH_HOME/profiles/headless/package.json". Expect the same plugin's range and version recorded separately, with one moved and the other untouched.

Notes on per-profile DSH plugin updates

1. Do not treat "update all" as "update all environments" — an update without a package name covers one profile's dependencies only.
2. One profile at a time is safer — it pinpoints which environment's update caused a problem.
3. Desktop goes through the app — the CLI cannot reach the desktop profile, guaranteed by the exclusive lock.
4. Get the custom profile name right — the value after --profile is your profile name, and a typo targets a different environment.
5. Run outdated before update — see which plugins in the target profile can actually move. Expect to avoid sweeping in a plugin you did not mean to touch.
6. Keep one profile un-updated as a baseline — leave one environment untouched. Expect a clean older version to compare against when something breaks.

To avoid typing commands for each profile, use the built-in DSH Plugin Hub: its installed list shows the DSH plugins and update status for the current environment, updates happen in a click, and a confirmation dialog sits in front.

Sources: DeepSeek Harness CLI README, DeepSeek Harness desktop README