How to Find DeepSeek Harness Plugins in 2026

DeepSeek Harness (dsh) does not ship an official plugin marketplace or registry. The only sanctioned discovery mechanism is a GitHub topic, dsh-plugin, that plugin authors are asked to tag their repos with. Everything else — awesome lists, in-app "plugin market" plugins, curated directories like this one — is community infrastructure built on top of that single, noisy signal.

That gap is worth understanding before you go looking for plugins, because it changes how you should evaluate what you find. Below is what actually exists, how each source works, and the one check that tells you whether a repo is a real dsh plugin at all.

Why there's no official marketplace

The dsh README asks plugin authors to add the dsh-plugin topic to their repository "for discoverability" — that's the entire official discovery story. There's no marketplace.json, no registry API, no curated list maintained by deepseek-ai. Searching the codebase for "marketplace" or "registry" turns up only internal Cordis framework concepts (the plugin loader's dependency graph) and a Claude Code environment variable used in dsh's subagent bridge — nothing related to a plugin store.

That's a deliberate trade-off of a project still in developer preview, but it also means anyone can build a "marketplace" and call it authoritative. Several already have.

The GitHub topic: broad, noisy, unfiltered

https://github.com/topics/dsh-plugin

As of August 2026, this topic tags several thousand repositories. It's the widest net you can cast, but it's entirely self-reported — a repo shows up here because its author added a tag, not because anyone verified it's a working plugin. Many results are forks, templates, abandoned experiments, or projects that merely mention dsh compatibility without shipping a working bundle.

The topic page is a fine starting point for browsing what's new, but it is not a trust signal by itself.

The one authoritative check: the `dsh` field in `package.json`

There's exactly one reliable way to tell whether a GitHub repository is a real, installable dsh plugin: open its package.json and look for a dsh field.

{
  "name": "dsh-hello-plugin",
  "dsh": { "bundle": { "patch": "./cordis.patch.yml" } }
}

A package that declares dsh.bundle is a bundle — it patches your configuration when installed. A package that declares dsh.profile is a full profile definition. A repository with the dsh-plugin topic but no dsh field in its package.json is not something dsh plugin add will treat as a plugin — pnpm will happily install it as a plain dependency, but dsh won't activate any config from it and will print a warning. This is the same field a curated directory checks before indexing a repo as a real plugin rather than noise from the topic search.

If you're evaluating a plugin before installing, this is step one — see the full process in our plugin security checklist.

Community awesome lists

The most useful curated resource right now is the community-maintained awesome-dsh-plugin/awesome-dsh-plugin repository — a hand-reviewed README that groups plugins into categories like UI Enhancements, Themes, Memory, Tools & Capabilities, Skills, Workflow & Automation, Notifications, Models & Providers, Development & Runtime, and Just for Fun. It's a third-party, community-run project, not an official DeepSeek asset, but the manual curation makes it meaningfully cleaner than a raw topic search.

Other community awesome lists exist with their own, differently-organized taxonomies — none of them share a standard category scheme, since there's no official one to converge on. Treat any of them as a starting point for research, not a certification.

In-app "plugin market" plugins

A specific sub-genre worth calling out: plugins whose entire purpose is to add a browsable plugin store inside the dsh Web UI. dsh-market adds a Settings page for browsing and searching a community catalog with one-click install; dsh-webui-market-plugin does something similar by surfacing the awesome-dsh-plugin catalog inside the GUI; dsh-find-plugin instead gives the agent itself a tool to search a curated registry by keyword or category, so you can just ask for what you need in conversation.

These are convenient, but worth being clear-eyed about: they are themselves ordinary dsh plugins, installed and executed the same way as anything else, and their "one-click install" convenience doesn't come with any additional vetting of the plugins they surface. Installing a market plugin doesn't make the plugins inside that market any safer to run.

Searching npm directly

Because dsh plugin add is a thin wrapper around pnpm add, npm is a legitimate discovery surface on its own, not just a distribution channel. Authors who publish prebuilt output (rather than only pushing source to GitHub) commonly tag their package with the dsh-plugin keyword, which you can search from the registry's public search API:

curl "https://registry.npmjs.org/-/v1/search?text=keywords:dsh-plugin"

The same caveat applies here as with the GitHub topic: the keyword is self-reported. A package can carry the dsh-plugin keyword and still not declare a dsh field in its package.json — the keyword gets it into search results, the field is what actually makes dsh plugin add recognize it as a plugin rather than a plain dependency. If a package does have both, it's usually the smoothest install path, since npm-published plugins ship prebuilt output and skip the allowBuilds prompt covered in our GitHub install guide.

Comparing the discovery sources

Source	Coverage	Curation	Trust signal
GitHub topic `dsh-plugin`	Widest (thousands of tagged repos)	None — self-reported	None; verify `dsh` field yourself
Community awesome lists	Medium (hundreds)	Manual, third-party maintainers	Better than raw topic search, still unofficial
In-app market plugins	Varies by market	Usually mirrors an awesome list or the topic search	Same as whatever list they pull from
FindHarness	800+ indexed, curated subset from the awesome list plus npm/topic discovery	`dsh` field verified before indexing	Directory only — not a security audit

FindHarness's own approach

This site indexes plugins from two tiers: a curated set sourced from the community awesome list, and a broader discovery set pulled from npm keyword search and the GitHub topic, filtered down to repositories that actually declare a dsh field in package.json. Browse the full catalog or jump straight into a category like Tools & Capabilities or Development & Runtime, which is where most of the diagnostic and plugin-management tooling mentioned in this series lives.

Being indexed here means a plugin passed the dsh field check and has a real GitHub repository behind it — it is not a security review. Read the plugin security checklist before installing anything you haven't personally inspected.

FAQ

Is there an official DeepSeek Harness plugin store?

No. The only official discovery mechanism is the GitHub dsh-plugin topic. Everything called a "marketplace" or "plugin store" — including in-app market plugins — is a third-party, community-built project.

How do I know if a GitHub repo is actually a working dsh plugin?

Open its package.json and look for a dsh field with a bundle or profile sub-key. That's the field dsh plugin add itself checks to decide whether to activate a config patch. No dsh field means it will install as a plain dependency at best, not a plugin.

Once you've found a plugin worth trying, read how to install DeepSeek Harness plugins for the exact dsh plugin add syntax, or go deeper on installing from GitHub specifically if the plugin isn't published to npm. Before you run the install command on anything you haven't audited yourself, walk through the plugin security checklist.