Are DSH Plugins Safe? A Practical Guide
Installing a DeepSeek Harness plugin means running someone else's code inside the harness you trust with your files, your sessions and your keys. This guide covers what an install actually executes, what a plugin can reach once it loads, what dshpacks verifies before a page goes live, and a five-minute check you can run yourself.
Short answer
A DSH plugin is not a theme file or a config snippet. It is code that the harness loads and runs as you. The ecosystem is young and mostly small: across the 2,961 plugins listed in this directory the median repository has 2 GitHub stars and 85% have fewer than ten. That is the same trust profile as any young open-source ecosystem — most of it is fine, a few entries are not worth the risk — and the difference is visible if you read the install line before you paste it.
Nothing in this guide is a security audit, and no plugin on this site has been executed by us. What follows is (a) how the install mechanics actually expose you, and (b) the checks we run — which you can run too.
What an install actually does
Across the 1,651 reviewed plugins, the published install commands fall into a handful of shapes. The counts below are a mechanical classification of the command string each README publishes, and the shapes are not equally exposed:
- Harness-managed package install — 1,349 entries use the
dsh plugin --profile … addform (1,188 of them on thewebprofile). The harness resolves the package and installs it into a profile, so the package's own install lifecycle runs on your machine, in your user context. - npm / npx lines — 97 entries prescribe an
npm install/npxcommand directly instead of the harness form. The same npm lifecycle caveat applies, plus whatever the package does the first time it runs. - Source checkout — 39 entries publish a GitHub or git form (
github:owner/repo, sometimes pinned to a tag). This puts source on disk; code executes when you build or activate it. - Python packages — 7 entries install through pip or uv.
- Downloads and manual steps — 91 entries document neither a package add nor a checkout: a release download (installer, DMG, MSI, tarball), a Homebrew/Cargo/Docker line, or a file you copy into place by hand. Here the trust question moves from a README to a binary or to a directory you populate yourself.
- Not confirmed — 68 entries are published here with the explicit note install command not confirmed, because the only thing the upstream README shows is a manual copy step, a path on the maintainer's own machine, or a private source. We do not invent a command to fill the gap.
The practical takeaway: the same plugin can be a one-line package add or a build-from-source exercise, and those are very different amounts of exposure. Read which one you are pasting.
What a plugin can reach once it loads
Once loaded, a plugin runs inside the harness, in your session, with the same reach your session has: the working tree, files the harness can read, network access, and any credential the harness is holding. That is not a defect in DSH's design — every plugin architecture works this way, including the ones you already trust — but it sets the bar clearly: install a plugin the way you would run a script from a stranger, because that is effectively what you are doing.
How we review a plugin before it gets a page
- The command is copied, never written. Every install command on a plugin page is the string the plugin's own README publishes. When we cannot find one, the page says the command is not confirmed instead of printing something plausible.
- The registry is cross-checked. For npm-published plugins we look the package up and compare the registry's repository field with the repository we are cataloguing. When the package is owned by a different repository, the page states that rather than implying a relationship. When a package publishes no repository field, we say the ownership could not be confirmed.
- Binary and installer plugins are checked against releases. Desktop shells and installer-based plugins are verified against published release assets and tags, not inferred from a version number that appears in prose.
- Non-pasteable forms are flagged, not printed. Local-checkout commands (absolute paths,
add "$PWD"), angle-bracket placeholders and packages that are not actually published are never rendered as commands you can copy. - The verification path is on the page. Where a maintainer documents a way to confirm the plugin loaded — a console line, a new panel, a CLI status — that note is carried onto the page, because a successful
addis not proof the plugin is running.
What we do not do
Be clear about the limits of a directory like this one. dshpacks does not execute plugin code, does not run static analysis on it, and does not perform security audits. A runtime-test verdict here means the documentation, package metadata and published artefacts were checked — nothing more. Stars measure popularity, not safety: some of the most-starred plugins are also the most powerful, and power is exactly what you are trusting.
Check a plugin yourself in five minutes
- Read the install line first. Is it a package add, a git checkout, or a build from source? If it is a build step, you are running the code you compile — read it.
- Compare the owner on both sides. The GitHub owner and the npm package owner should be the same project. When they are not, find out why before you install.
- Look at what runs on install. Packages that define pre/post-install scripts, or that ship prebuilt binaries, do more than copy files.
- Keep experiments out of your main profile. The commands in this directory target several profiles (
web,tui,demo,headless,default). Installing an unfamiliar plugin into a profile you do not use daily keeps it away from the one you do. - Ask what it needs and why. A UI tweak that wants broad filesystem or network access is worth a second look; a plugin's request should match the job its page describes.
If you want to remove one
Installs are per profile, so removal is the inverse of the install. 140 of the reviewed entries document this form upstream:
dsh plugin --profile web remove <package-name>If you added a plugin from a source path or a local checkout rather than a published package, remove it the same way you added it, using the same identifier. Restart the harness afterwards so the profile reloads without the plugin.
Where to go next
- How to install DSH plugins — the exact command forms, including the GitHub fallback
- Best DeepSeek Harness plugins — reviewed picks, ranked by category
- dsh Packs — curated shortlists of reviewed plugins by use case
- The plugin directory — every reviewed plugin with its verdict and verified command
Related: Install guide · Submit a plugin for review
Where to go next
- Best DeepSeek Harness plugins — ranked picks by category
- How to install DSH plugins — step-by-step guide
- DSH plugin FAQ — 20 questions answered
- DSH vs Claude Code vs Codex — harness comparison
- Pi vs DSH vs Claude Code — the context-management debate
- dsh Packs — curated bundles of reviewed plugins
- The plugin directory — every reviewed plugin, searchable
- DSH ecosystem report — the numbers behind the directory
- DeepSeek Harness tutorial — get dsh running, step by step
- DeepSeek Harness vs OpenCode — how the two open agent harnesses differ
- DeepSeek Harness review — the harness and its plugins, assessed