Install one DSH plugin into multiple profiles: isolation

The same DSH plugin only takes effect in the profile you installed it into — installing into web will not make it show up in the desktop app, and vice versa. That is because each profile has its own $DSH_HOME/profiles/<name>/package.json and node_modules, while only sessions, global settings, and credentials are shared. To make a plugin available everywhere, install it once per profile; the only profile you cannot touch this way is the desktop-exclusive desktop profile.

DSH plugin profiles are invisible to each other: web is not desktop

Plugins hang off profiles, not off the machine — that is the root cause of "I cannot see it". Three points:

1. Each profile is a self-contained set: $DSH_HOME/profiles/<name> holds its own package.json (dependencies and dsh.profile.bundles), cordis.patch.yml, and node_modules. A plugin installed in A never appears in B.
2. Marketplace installs also target a profile: when you click install in DSH Plugin Hub, the plugin still lands in one specific profile rather than applying globally. To install into several profiles, install once inside each one.
3. One plugin in two profiles is two independent instances: they each have their own config and lifecycle, and changing a setting in one does not affect the other.

The one exception is the desktop profile: it is exclusively owned by the desktop app — before touching any profile the desktop app takes a process-lifetime single-instance lock and exclusively owns $DSH_HOME/profiles/desktop and its package manager state, so neither a plain CLI nor an npm-installed dsh can start or modify it; only the desktop app's built-in commands can manage its plugins after the app quits (source).

Installing the same DSH plugin profile by profile: syntax, order, and what is shared

The syntax is simple: run the same add command once per --profile value. Three cases:

1. Two known profiles, one install each:

dsh plugin --profile web add <package>
dsh plugin --profile desktop add <package>

--profile is required and decides which manifest and which node_modules gets touched; the two commands have no ordering dependency on each other (source). The full form of add is in the dsh plugin add command.

2. Installing into a brand-new profile name: no manual creation needed. When the profile directory does not exist, dsh plugin initializes it from a template before running pnpm — built-in profiles such as web use the bundled template, other names use @deepseek-ai/dsh-base. So the first dsh plugin --profile <newname> add <package> creates the profile along the way.

3. Installing into the desktop profile: you must launch the desktop app once so it prepares the profile, then quit the app completely and install with the desktop app's built-in commands — a plain CLI is refused and will not create a same-named ordinary profile for you either. Full prerequisites and limits are in desktop dsh commands.

Distinguish what is shared from what is not: under one $DSH_HOME, sessions, settings.yaml, and .credentials.yaml are shared, so switching profiles does not mean reconfiguring model credentials; profiles/<name> stays separate, with plugins and dependency manifests kept per profile. The directory layout is in where the DSH config file lives.

Verifying profile by profile which DSH plugin went where

The rule: query each profile once and never reuse another profile's result. Three steps:

1. List the profiles on this machine:

ls "$DSH_HOME/profiles"

Expected: names such as web, headless, desktop that you have used; if unsure about $DSH_HOME, run echo $DSH_HOME first.

2. Query the package per profile:

dsh plugin --profile web list | grep -n "<package>"
dsh plugin --profile desktop list | grep -n "<package>"

Output means it is installed in that profile; no output at all means it never went there. How to read list is in how to use dsh plugin list.

3. Check the load layer, not just the package:

dsh --profile web --dump-config | grep -n "# =="

Only when a # == <package> layer appears will it actually be loaded in that profile. A package present in list without that layer means it was installed as an ordinary dependency that does not declare dsh.bundle.

Note: verifying the desktop profile requires the desktop app's built-in commands — a plain CLI list will not read it for you.

DSH plugin multi-profile install notes

Remember one line: plugins follow the profile, settings and sessions follow $DSH_HOME.

1. Decide which profile you are targeting before installing: installing into the wrong one wastes the install and forces an uninstall later.
2. --profile cannot be omitted: omitting it exits non-zero, and it decides the target — a wrong name installs into a brand-new empty profile.
3. Do not treat the desktop profile as an ordinary profile: a plain CLI cannot modify it; plugin installs must go through the desktop app's built-in commands.
4. The desktop profile must be initialized first: running the built-in commands before ever launching the desktop app is refused with "profile not initialized".
5. Multiple profiles mean multiple maintenance costs: one plugin in three places must later be upgraded three times, so install only where needed.
6. To find out how many profiles hold a plugin: run list once per candidate profile, rather than trusting your memory.
7. Switching profiles does not affect credentials: settings.yaml and .credentials.yaml are shared, so switching profiles does not mean reconfiguring the API key.

Sources: DeepSeek Harness CLI README, DeepSeek Harness desktop README, official docs - Packaging and installing a plugin.