Move DSH plugins to a new machine via market manifest

I moved my working setup to a new laptop last month and assumed the DSH Plugin market would make the migration trivial. The packages were easy; the behavior was not, because versions and profile settings do not travel by themselves. Here is what actually followed me, what I had to reinstall, and how I proved the new machine behaved like the old one.

What followed my DSH plugin list to the new machine

Only what I wrote down followed me, and the installed DSH plugin list was the most valuable note I kept.

Before touching the old machine, I exported the current profile with dsh plugin list and pasted the output into a plain text file. That gave me package names and exact versions instead of a vague memory of what I used. I added the profile name next to each line, because several plugins loaded only in my work profile. The manifest was short, but it answered questions the market could not answer for me.

I also wrote down environment variable names, credential references and the config files I had edited by hand. I did not copy the secrets themselves into the manifest; I recorded where they came from so I could recreate them safely. The plugin directories stayed behind, because copying them would have carried native artifacts and links that do not survive a move.

What I had to reinstall as DSH plugins

Every package had to be installed again on the target, by exact version rather than by name.

Installing by name would have pulled the latest release and quietly changed behavior I depended on. I used the manifest as a checklist and installed one package at a time, starting with the plugins my daily work touches. Each install command named both the package and the version I had exported. When a version had disappeared from the registry, I stopped and decided explicitly whether to accept the nearest release.

I kept the package manager close to the old version, because lockfile and build differences can turn a clean migration into a debugging session. Plugins with native modules rebuilt for the new machine's architecture, which is exactly why the copied directory would have failed. The registry had to be reachable from the new network before any of this could work.

I installed core plugins first and verified before continuing, so a failure stayed local. The command below is the shape I used, with manifest values substituted for the placeholders. Keeping each batch small also kept the install output short enough to read.

dsh plugin add <package>@<version>

Preparing a DeepSeek Harness plugin target

The target machine needed a compatible host before any plugin could load.

I checked the old machine's Harness version first and matched it on the new one rather than jumping to the newest release. Compatibility is declared by the plugin, but the host still has to satisfy the range the plugin expects. A major version gap would have made the reinstall pointless, so I read the release notes before choosing. Once the host version matched, the plugin installs had a stable target.

I confirmed that the data directory was writable, because a permissions problem there looks like a plugin that installs but never loads. I tested registry access with one small package before migrating the rest. That single end-to-end install exercised the network, the build toolchain and the directory permissions at once.

Verifying the DSH plugin migration

Installation is only the start; the migration is done when plugins load, behave and keep their settings.

I restarted the client and watched each plugin reach an active state instead of staying pending or failed. For a plugin that touches files or commands, I ran one real operation rather than trusting the status badge. I compared configuration values, paths and credential references against the notes from the old machine. Then I opened a new session and confirmed that its tools and commands were present.

The checks that mattered were the ones that exercised behavior, not the ones that only proved a package existed. A plugin can be installed, active and still wrong because a profile setting points at an old path. Keeping the old machine nearby made it possible to compare without guessing.

1. Compare dsh plugin list with the exported manifest line by line.
2. Restart the client and confirm every plugin reaches an active state.
3. Run one real file or command operation for each privileged plugin.
4. Confirm profile-specific plugins load only in the right profile.
5. Check paths, environment variables and credential references.
6. Keep the old machine until all of these checks pass.

That list became my definition of done, and I did not delete the old setup until every line passed. The order matters less than the rule that installation alone never counts as migration. An extra hour of checking is cheaper than discovering a missing permission a week later.

What I would do differently in the next DSH plugin migration

The manifest was worth more than any backup of the plugin directory, and I would start it earlier next time.

I would record versions continuously instead of exporting them on the day of the move. A manifest that is updated when a plugin is added is more reliable than a screenshot or a memory of the setup. I would also note the reason each plugin is installed, so the next machine can drop the ones that no longer earn their place. That note turns a migration into a review rather than a copy.

I would not copy plugin directories, and I would not install the latest version just because it is easier. Any version difference should be a decision with a reason, not a side effect of a default. DSH plugins are small enough to reinstall cleanly, and a DeepSeek Harness plugin that behaved differently after the move was always a configuration or version problem, never a missing directory.

Sources: DSH Plugin Hub entry, DeepSeek Harness quickstart, npm @deepseek-ai/dsh.