dsh plugin list: installed plugins and profile scope

The full form of dsh plugin list is dsh plugin --profile <name> list, which forwards its arguments to the pnpm in the profile directory and is equivalent to running pnpm list there. But "installed plugins" has two answers: list reports pnpm dependencies, while the profile's dsh.profile.bundles decides which plugin layers actually load — and the two counts frequently disagree (source).

DSH plugin overview: two counts to read

In DSH, "which plugins are installed" has two answers: one from pnpm dependencies (dsh plugin list) and one from the profile's bundle manifest (dsh.profile.bundles), and they do not answer the same question. Keep three things straight:

1. dsh plugin list reports the npm dependencies in $DSH_HOME/profiles/<name> — it answers "is the package on this machine";
2. dsh.profile.bundles records which plugin layers are applied, in order, when the profile boots — it answers "what actually loads at runtime";
3. They are not equivalent: in-box bundles are absent from the first, and packages without a dsh.bundle declaration are absent from the second.

Hold onto that distinction and every "why don't the numbers match" question answers itself.

How dsh plugin list works: forwarded to pnpm, flags unchanged

dsh plugin --profile <name> <args...> forwards everything after --profile to the pnpm in that profile's directory, so list is pnpm's list (alias ls) and every pnpm flag applies (source). Three steps to start:

1. Get the profile name. dsh web boots the built-in web profile; web and headless auto-initialize from shipped templates on first use, and any other profile must be created through the dsh plugin channel.

2. Run the default query, which lists direct dependencies only:

# --depth 0 is the default; direct dependencies only
dsh plugin --profile web list

pnpm list defaults to --depth 0, so the plain command already returns direct dependencies rather than a full tree (source).

3. Switch output shape as needed:

# Full dependency tree
dsh plugin --profile web list --depth Infinity

# dependencies only, skipping devDependencies
dsh plugin --profile web list --prod

# JSON, handy for scripts
dsh plugin --profile web list --json

# Filter by a positional name pattern
dsh plugin --profile web list "dsh-*"

Installing plugins goes through the same channel; see dsh plugin add: --profile, targets and verification for the full add syntax and target formats.

Reading the DeepSeek Harness installed list: pnpm deps vs dsh.profile.bundles

dsh plugin list and the length of the profile's dsh.profile.bundles regularly disagree for two reasons: in-box bundles resolve from the dsh installation and never enter the profile's node_modules (so list cannot see them), while packages without a dsh.bundle declaration install but activate no layer (so list shows them anyway) (source). Read them in this order:

1. See what pnpm has installed:

dsh plugin --profile web list

2. Read the profile's dependencies and bundle manifest — same file, two owners: dependencies is pnpm's business, dsh.profile.bundles is dsh's:

cat ~/.dsh/profiles/web/package.json

The shape is:

{
  "dependencies": { "<third-party plugin>": "…" },
  "dsh": {
    "profile": {
      "bundles": ["@deepseek-ai/dsh-base", "<third-party plugin>"]
    }
  }
}

3. Reconcile the two counts. In-box bundles such as @deepseek-ai/dsh-base, @deepseek-ai/dsh-web-app and @deepseek-ai/dsh-headless always resolve from the dsh installation itself; pnpm only manages out-of-tree packages (source) — so bundles containing more entries than list is expected.

4. Confirm the inverse case: installed but inactive. If a package is in list but not in bundles, it is a plain dependency with no dsh.bundle declaration. dsh plugin warns about this at install time and activates no configuration layer (source).

5. Settle it without booting, using the composed tree:

dsh --profile web --dump-config

Every active bundle prints a # == <package> layer, and that output is the final word on what actually loads at runtime (source).

Listing DeepSeek Harness plugins per profile: a different name, a different list

Plugins are installed onto a profile, not globally — dsh plugin --profile <name> list runs pnpm list inside $DSH_HOME/profiles/<name>, so changing the name shows a completely different set. The order to work in on a multi-profile machine:

1. See which profiles exist:

ls ~/.dsh/profiles

2. Query each candidate profile to find where the plugin actually landed:

dsh plugin --profile web list
dsh plugin --profile headless list

3. Debug "it has no effect" in the right direction: first confirm the plugin is in the profile you actually boot (dsh web uses web), otherwise you installed it into a different one.

4. Do not confuse app arguments with profile selection. The launcher parses only its own flags, so in dsh --profile web --port 8080 the --port belongs to the web app; the first token the launcher does not recognize starts the app's arguments (source).

DSH plugin list: things to watch out for

In short: list shows dependencies, bundles shows loading, mismatched counts are normal, and --dump-config settles the argument. Four reminders:

1. Do not use the list count as "active plugins". It omits in-box bundles and includes library packages that activate nothing.
2. Parse --json in scripts, not tree text. Indentation and glyphs change between versions; the JSON flag stays stable.
3. Be careful with large --depth values. Profile dependency trees can get deep, and --depth Infinity produces very long output; --depth 0 is usually enough for debugging.
4. list is read-only. It will not touch package.json or pnpm-lock.yaml, so run it freely.

Skip the reconciliation? Let DSH Plugin Hub show you one answer

All that triangle-checking between pnpm dependencies, the bundles manifest and dump-config collapses into one screen. Once DSH Plugin Hub is installed, open Settings → Installed: it shows the current environment's plugin list with source tags (catalog / manual), version and update time, plus update and uninstall actions at the end of each row. Search, source filters and sorting by name or stars are built in. Rather than diffing two lists in a terminal, let the market put "what is installed and what can be updated" on a single screen.

Sources: dsh CLI README, DeepSeek Harness docs - Package and install a plugin, pnpm list (pnpm ls) command reference