What happens when you click Install in the DSH plugin market

Clicking Install in the DeepSeek Harness plugin market runs one dsh plugin --profile web add <package>: the package manager fetches the package, writes it into that profile's node_modules, and updates the profile's dependency record (source). There is no separate mechanism behind the interface; it presents a command's inputs, progress and result as a button and a progress bar. This article covers which command the button maps to, where files land, and how to reproduce the same step.

Which command the plugin market Install button maps to

The equivalent command is dsh plugin --profile <name> add <package-or-repo>, where --profile takes the value of the profile the interface belongs to (source). One click breaks into three actions:

So the command in the confirmation dialog is not decorative — it is exactly what this click will execute, and copying it is how you reproduce the step.

Where DSH plugin files land

The destination is the current profile's node_modules, at $DSH_HOME/profiles/<name>/node_modules; when $DSH_HOME is unset it defaults to ~/.dsh (source). Four steps to see the structure:

1. Look at the profile directory — run ls "$DSH_HOME/profiles/web". Expected: package.json, configuration and node_modules all appear.
2. Look at the top level — run ls "$DSH_HOME/profiles/web/node_modules". Expected: top-level directory names match installed packages, and most are symlinks.
3. Find the real files — enter node_modules/.pnpm. Expected: package content laid out per <name>@<version> (source).
4. Read the dependency record — open the profile's package.json. Expected: the plugin sits in dependencies, and dsh.profile.bundles lists the bundles to activate.

One easy misreading: the built-in base, web and headless bundles do not resolve from the profile directory, so their absence from a profile's node_modules is expected rather than a failed install. See where DSH plugins are installed.

Reproducing the DSH plugin market install manually

Reproducing means doing in the terminal what the interface did: copy the dialog's command and run it with the correct --profile. Four steps:

1. Install the market entry first — run dsh plugin --profile web add dsh-plugin. Expected: after a restart, Settings shows the DSH Plugin Hub plugin market.
2. Pick a plugin and click Install — open Settings → Plugin Market and click Install on a card. Expected: a confirmation dialog appears with the plugin name, source and the command about to run.
3. Copy the command and run it — paste it into a terminal, keeping --profile aligned with the interface. Expected: the output matches the interface progress and the plugin appears under Installed.
4. Verify in two places — run dsh plugin --profile web list, then check the plugin market's installed list. Expected: both show the plugin with the same version.

For the command's own flags and exit codes, see the dsh plugin add command.

The plugin market visualises the fetch, write and record steps, while the CLI hands you the same flow directly; both act on one body of data.

Notes and limits on the DSH plugin install mechanism

1. The interface adds no mechanism: the plugin market's Install and the CLI add are one implementation, with the interface presenting process and outcome.
2. The profile decides the destination: the same plugin in two profiles is two independent records, and neither entry point sees the other's copy.
3. Symlinks are not shortcuts: the top level is only an entry point, so edit files in .pnpm or you will see changes that never take effect.
4. Built-in bundles are the exception: base, web and headless resolve from the host and never enter a profile directory.
5. Install is not activation: written dependencies are not the same as a loaded plugin, and both dsh.profile.bundles and a restart are required.

Sources: dsh CLI README, Packaging and installing plugins (official docs), pnpm symlinked node_modules structure, dshplugin/dsh-plugin-hub