How to Install DeepSeek-Harness Plugins (2026 Guide)

To install a DeepSeek-Harness (dsh) plugin, run:

dsh plugin --profile <profile-name> add <specifier>

For example, to add modlens — one of the highest-starred plugins in FindHarness's curated (awesome-list) index — into your web profile:

dsh plugin --profile web add github:liustack/modlens

That's the whole command. The rest of this guide covers what <specifier> can be, what happens under the hood, and the one security prompt you should actually read before clicking through it.

What the command is really doing

dsh plugin --profile <name> <args...> first makes sure the profile exists (initializing it if needed — web and headless are hardcoded starter templates, any other name just bootstraps with the base bundle @deepseek-ai/dsh-base). It then forwards everything after the profile flag as-is to pnpm, run inside that profile's directory. That means add, remove, update, and why are not dsh-specific commands — they're literally pnpm subcommands, so pnpm needs to be on your PATH.

If the package you install declares a dsh.bundle field in its package.json, dsh automatically registers it into the profile's active bundle list. If it doesn't declare that field, it still installs as a normal dependency, but dsh prints a warning and doesn't activate any config — useful for pulling in a plain library a plugin depends on, without dsh trying to treat it as a plugin itself.

The three supported sources

Because installation is just pnpm underneath, <specifier> accepts anything pnpm accepts. In practice, three forms cover almost every real case.

1. npm registry (recommended when available)

dsh plugin --profile demo add your-package

This is the officially recommended path — the plugin author publishes prebuilt output to npm, so there's no build step and no build-permission prompt at install time. As of this writing, the plugins indexed on FindHarness are, without exception, distributed straight from their GitHub repositories rather than published npm packages — this is a young, fast-moving ecosystem, and most authors haven't set up an npm release yet. So in practice you'll be reaching for the GitHub form below far more often.

2. GitHub repository

dsh plugin --profile tui add github:owner/repo

Real examples you can run today, pulled straight from the FindHarness index:

# Vision bridge for text-only models (1308 stars) — see /plugins/liustack-modlens
dsh plugin --profile web add github:liustack/modlens

# Multi-agent team orchestration (250 stars) — see /plugins/nanmicoder-dsh-agent-teams
dsh plugin --profile web add github:nanmicoder/dsh-agent-teams

# Cross-session memory vault (16 stars) — see /plugins/omdsh-dev-dsh-mnemon
dsh plugin --profile web add github:omdsh-dev/dsh-mnemon

You can pin to an exact commit with #<sha> — github:owner/repo#a1b2c3d. Do this for anything you don't personally maintain: without a pin, a later push to the same branch silently changes what code you're running the next time you reinstall or update.

3. Local path or tarball (for plugins you're developing)

# a folder on disk, resolved relative to your current directory (not the profile's)
dsh plugin --profile demo add ./hello-plugin

# a tarball produced by `pnpm pack`
dsh plugin --profile demo add ./hello-plugin-0.1.0.tgz

One gotcha worth calling out explicitly: a relative local path is resolved from wherever you ran the add command, not from the profile directory. Run it from the wrong folder and you'll either get a confusing resolution error or, worse, install the wrong directory.

When you'll hit the allowBuilds prompt — and why it matters

GitHub installs pull down source code, not build output. If the plugin is TypeScript and doesn't ship a compiled lib/ directory in the repo, it needs to build itself after install, which plugin authors handle with a prepare script in package.json.

Here's the catch: pnpm 10 and later blocks prepare scripts on git dependencies by default. The first time you add a GitHub-sourced plugin that needs one, the install will fail, and pnpm will tell you to explicitly allow it in the profile's pnpm-workspace.yaml:

allowBuilds:
  dsh-hello-plugin: true

Before you paste that in, know what you're agreeing to. The dsh docs state this plainly, and it's worth repeating in full:

Treat that allowance as what it is: permission to execute the package's code on your machine at install time, outside any sandbox the agent runs under. Only allow packages whose source you trust, and pin a commit.

That's not boilerplate legal language — it's an accurate description of what allowBuilds does. It runs arbitrary code from that package during pnpm install, before dsh's own runtime sandboxing has a chance to apply to anything. Two practical takeaways:

1. Only flip allowBuilds: true for plugins whose source you've actually looked at, or that come from an author/organization you already trust.
2. Combine it with a commit pin (github:owner/repo#<sha>) so a future push to the source repo can't change what gets built and run on your machine the next time you reinstall.

If you'd rather avoid the prompt entirely, that's a signal to prefer plugins published to npm with a prebuilt lib/ — no prepare script needed, no build-permission decision to make.

Updating and removing plugins

Plugin versioning is plain pnpm/npm semantics — there's no separate dsh version system:

# update everything in a profile
dsh plugin --profile demo update

# update one plugin
dsh plugin --profile demo update dsh-hello-plugin

# see why a package is installed (pnpm why, scoped to the profile)
dsh plugin --profile demo why dsh-hello-plugin

# remove a plugin
dsh plugin --profile demo remove dsh-hello-plugin

After any dsh plugin command, dsh re-scans the profile's actual installed dependencies and syncs the bundle list accordingly — removed packages drop out of the active configuration automatically, and newly-added ones with a dsh.bundle field get activated. You don't hand-edit the profile's package.json bundle list yourself.

Common issues

• "command not found: pnpm" — dsh plugin shells out to pnpm directly; install it and make sure it's on PATH.
• Install fails immediately after a GitHub add — almost always the allowBuilds prompt above. Check pnpm-workspace.yaml in the profile directory.
• "Cannot find module" after a GitHub install — the plugin likely needs a build step that didn't run; check whether it ships a prepare script and whether the build permission was granted.
• A local path install can't find your plugin — remember the path is relative to your current shell directory, not the profile's.

Try it

Browse the full, searchable catalog at /plugins — every entry shows its real star count, license, and README, plus the exact install command for that plugin. Or start with our picks in 10 Best DeepSeek-Harness Plugins in 2026.