DeepSeek Harness Plugins: Counting What 'Everything Is a Plugin' Means in Practice

DeepSeek describes Harness as a system in which components such as the model layer, sessions, and timer are implemented as plugins. We inspected version 0.2.1-rc.5 to see what this means in the shipped profiles. The web profile contains 191 plugin entries from 187 distinct packages, with 32 entries disabled by default; the headless profile contains 98 entries. We also found that the dsh plugin command forwards commands to pnpm. On Windows, it failed when pnpm was not available on PATH. Finally, installing an ordinary npm package did not make it a Harness plugin: the package needed to declare dsh.bundle.

The configuration dump showed 191 entries in the web profile, including the LLM bridge, sessions, timer, hot reload, and plugin manager. The command dsh --profile web --dump-config prints the composed configuration without starting the profile. We also checked how the plugin command works. The command dsh plugin --profile <name> add <pkg> passes the arguments to pnpm in that profile's directory, so pnpm must be installed and available on PATH. In our Windows test, the command failed until we installed pnpm. The 187 core packages are resolved from the Harness installation itself, which explains why a new profile's package.json can have an empty dependencies object. To check whether adding a package makes it a Harness plugin, we installed nanoid in a disposable profile. pnpm installed it in 8.7 seconds, but Harness warned that it did not declare dsh.bundle. The package was therefore installed as a regular dependency, not as a plugin.

Counting the stack: 191 entries in web, 98 in headless

The command that makes this measurable is dsh --profile <name> --dump-default-config: it prints the composed plugin tree and exits - no boot, no key, no browser. We ran it for both shipped profiles and counted:

Sample of what is actually in there, from the top of the web dump: dsh-plugin-manager, cordis-plugin-timer, dsh-hmr (hot reload), dsh-llm, dsh-deepseek-llm-api-extensions, dsh-session, dsh-session-log-deepseek, dsh-typert-registry. The kernel is not DeepSeek's either - the dump and the official page both point to Cordis, an open-source plugin framework (github.com/cordiverse/cordis), and Harness is built as an ordered stack of patch layers on top of it.

This count is useful when interpreting startup errors. In our installation test, 17 plugins failed because they encountered the same zod import error. A shared dependency problem can therefore affect several plugins at once. The 191 entries describe the size of the configured stack; they do not mean that 191 independent features are being loaded successfully.

The plugin CLI forwards to pnpm - and fails without it

The command reference describes dsh plugin --profile <name> <pnpm-args...> as forwarding its arguments to pnpm in the profile directory. This means pnpm must be installed and available on PATH, even if Node.js and npm are already installed.

On our Windows machine - Node and npm present, pnpm not - the first attempt produced:

dsh: plugin command failed; diagnostics: D:\...\profiles\web\.plugin-manager\logs\operation-…\pnpm.log

The log showed that Windows could not find the pnpm command. The diagnostics file was saved under the profile directory. After we installed pnpm globally with npm install -g pnpm (version 12.16.1), the same command completed successfully. If a dsh plugin command fails on Windows, check whether pnpm is installed and available on PATH, then inspect the diagnostics log.

On a shipped profile, dsh plugin --profile web list returned no entries and exited with code 0. This is expected in this setup: the core bundles are resolved from the dsh installation rather than listed as dependencies in the profile's package.json. The local package list may therefore be empty before you add an external package.

What dsh plugin add actually does, watched in a disposable profile

We installed a package into a profile that did not exist beforehand, to see the whole lifecycle:

dsh plugin --profile plugtest add nanoid

We observed three steps when adding a package to a profile:

1. The profile was created on first use. A plugtest directory appeared under $DSH_HOME/profiles/. It contained a package.json file for the base stack, cordis.patch.yml, and pnpm workspace files. According to the README, shipped profile names use their supplied templates, while other names are created from a base profile.
2. pnpm did the install. "Progress: resolved 1 … added 1, done. dependencies: + nanoid 6.0.2. Done in 8.7s using pnpm v12.16.1." The package landed in the profile's own node_modules, the lock file updated, and the profile's package.json now reads "dependencies": {"nanoid": "^6.0.2"}.
3. dsh told us it was not a plugin. Right after pnpm finished: "dsh: warning: nanoid declares no dsh.bundle - installed as a plain dependency, not a profile layer."

Harness displayed a warning after pnpm finished: "nanoid declares no dsh.bundle - installed as a plain dependency, not a profile layer." This means that the package was added to node_modules but was not registered as a Harness plugin. A package must declare dsh.bundle to join the profile's plugin layers at startup.

The documented removal command is dsh plugin --profile <name> remove <pkg>. Other pnpm commands, including why and outdated, are also passed through. The plugin manager checks compatibility against the runtime's engines.dsh range during installation and startup. The documentation also describes an exemption mechanism (version-exemptions / allow-version) for users who choose to proceed with an incompatible version.

The in-app side: what we could see and what needs a live model

The web interface sidebar includes a Plugins entry (shown as 插件 on our Chinese-language test machine), alongside sessions and automation tasks. DeepSeek's official product page also shows a demonstration in which an agent creates and installs a plugin through a plugin_manager · install_bundle tool call. In that demo, the agent creates a dsh-plugin-pomodoro-float package during the conversation. GitHub has a dsh-plugin topic for published projects.

We did not test the in-app plugin pages or the conversational plugin-creation feature. Those features require a configured model, and our test machines did not have a funded DeepSeek API key. We confirmed that the sidebar entry exists, but we cannot report how the in-app workflow behaves in practice. The plugin-creation example comes from DeepSeek's own demonstration, not from our testing.

What this architecture buys you, and what it costs

The following points summarize what we observed while inspecting and modifying the profiles:

• Advantage: The configuration can be inspected before startup. The --dump-config command prints the plugin layers, which can help when investigating a startup failure or comparing a profile's cordis.patch.yml with the default configuration.
• Advantage: Plugin installation uses pnpm, including its lockfiles and version controls. The plugin manager also checks compatibility and requires an explicit exemption to bypass a compatibility restriction.
• Limitation: The plugin command depends on pnpm. Profile configuration is also spread across package.json, a lockfile, and patch YAML, so copying a profile between machines involves more than one file.
• Limitation: The plugin count can be misleading. Most of the 187 distinct packages in the web profile are part of the underlying infrastructure, not optional add-ons selected by the user. We have not measured how many additional plugins an ordinary user would choose to install.

Based on our Windows tests, the CLI plugin commands worked after pnpm was installed, and the configuration dump was useful for inspecting a profile before startup. We did not test the in-app plugin-authoring workflow, so that part should be treated as unverified beyond DeepSeek's demonstration. If you are evaluating Harness, start by inspecting the default configuration with --dump-default-config.

Frequently asked questions

Do I need pnpm installed to use DeepSeek Harness plugins?

Yes. The dsh plugin command passes its arguments to pnpm in the profile directory. If pnpm is not available on PATH, the command returns an error and writes a diagnostics log. Installing pnpm resolved the problem in our Windows test.

Why is dsh plugin list empty on a fresh profile?

Shipped profiles resolve their core bundles from the dsh installation itself, so the profile's own package.json starts with an empty dependencies object. pnpm has nothing local to list until you add an out-of-tree package yourself.

How do I tell a real plugin from a random npm package?

A package must declare dsh.bundle to be recognized as a Harness plugin. If it does not, Harness warns that it was installed as a plain dependency rather than a profile layer. It remains in node_modules but is not added to the plugin stack.

How many plugins does DeepSeek Harness ship with?

Measuring plugin entries in the composed default tree: 191 in the web profile (187 distinct packages, 32 disabled by default) and 98 in headless, on 0.2.1-rc.5. Most are infrastructure - the LLM bridge, sessions, timer, hot reload - not optional add-ons.

Can the agent install plugins by itself during a chat?

DeepSeek's official demo shows an agent session creating and installing a plugin via a plugin_manager tool call. We have not reproduced this - the in-app flow needs a live model, and we test without funded keys.

Sources and what we could not test

The in-app plugin pages and any conversational plugin creation (creator mode) require a configured, funded model, which we deliberately do not keep on test machines - everything about the in-app flow here is structural observation or the vendor's own demo, labeled as such. We also did not remove the disposable profile through dsh (we deleted it from disk after the test), so 'remove' is documented behavior, not something we watched. Third-party plugins from the dsh-plugin topic were not installed or audited for safety.