What Are dsh Plugins? DeepSeek Harness Plugins Explained

The one-sentence answer

A dsh plugin is a Cordis plugin that adds to — or outright replaces — some part of DeepSeek Harness, the open-source agent runtime from DeepSeek. Cordis is the meta-framework underneath dsh: it handles loading, unloading and dependency resolution, and plugins cooperate through services and events.

The crucial difference from a browser extension or a VS Code add-on: a dsh plugin is not a bolt-on at the edge of the product. In dsh, everything is a plugin — the model adapter, the tool registry, the approval policy, the session log, the sandbox, the Web UI, even the main agent loop. A community plugin sits at the same level as a built-in one, which is why it can change so much.

What a dsh plugin can do

Because plugins plug into every seam of the runtime, the range is wide:

• Add tools the model can call — search providers, database connectors, title generators;
• Swap the UI — skins, sidebars, status bars, whole panels (the Web UI is a second plugin tree with declared mount points);
• Change the agent's behavior — intercept tool executions to approve, log or rewrite them; add guards against loops and timeouts;
• Provide infrastructure — sandbox backends, model providers (any OpenAI-compatible endpoint), session storage;
• Replace the loop itself — alternative agent loops, orchestrators and multi-agent setups;
• Mount other agents — register your local Codex or Claude Code as sub-agents the harness delegates to.

The directory sorts all of this into 22 categories — from MCP servers and agent workflows to themes and desktop pets.

The anatomy of a plugin

Conceptually, every dsh plugin is a function (or an object with lifecycle hooks) that receives a Cordis context and uses it to declare two things: what it provides (services, tools, UI components) and what it consumes (other plugins' services, events). Capabilities are split into service / provider / consumer roles, so the model always sees a stable interface no matter which provider sits behind it.

One rule the ecosystem enforces: registration must be reversible. When a plugin is removed, everything it registered is revoked — nothing leaks into later sessions. That guarantee is what makes trying random plugins from the internet survivable.

Where plugins live: bundles, profiles, patches

A running dsh is a plugin tree assembled from config layers that stack in a fixed order:

1. Bundles — official sets of plugins shipped together (the default experience);
2. Profiles — your named assemblies on top of bundles;
3. Patches — your override layer, addressable down to a single plugin entry.

Upper layers override lower ones. So "your dsh" is literally a stack of config files — which also means sharing a setup is just sharing those files. The full mechanics are in the configuration guide.

How installing one actually works

There is no dsh install <plugin> command. Installing a plugin means adding one entry to your profile or patch config — the exact line is documented in each plugin's README — and restarting so the tree is reassembled. Removing the entry uninstalls it, cleanly and completely.

Before you add that line, do the five-minute check: read the README, check the license, skim the entry points, look at recency, prefer curated entries. Plugins are code that runs with the agent's permissions, so the harness wraps them in sandbox tiers and approvals — but vetting is still on you. The full routine: installing dsh plugins safely.

Where to find them

• This directory — browse by category, stars or recency; detail pages show license, language, activity and source lists;
• The dsh-plugin GitHub topic — the official marker for community plugins, and how the wider ecosystem discovers them;
• The community awesome lists — mapped in the ecosystem guide.

FAQ

Are dsh plugins safe? They are code running with the agent's permissions, so treat them like any third-party dependency: read the source, check the license, try them in a disposable workspace at read-only first. The harness's sandboxes, approvals and guards contain misbehavior — they don't eliminate the need for judgment.

Do I need to restart dsh after installing a plugin? Yes — the plugin tree is assembled at startup, so config changes take effect on the next launch.

Can I write my own dsh plugin? Yes — it's a normal Cordis plugin in TypeScript. Start from the plugin template, follow the reversibility and config conventions, add the dsh-plugin topic to your repo, and open a PR to the awesome list to get listed. The plugin development guide walks through all of it.

How many dsh plugins are there? Thousands and growing — this directory syncs the ecosystem daily and ranks entries by stars, forks, recency and heat.

Keep exploring

• How to install DeepSeek Harness plugins
• What is DeepSeek Harness? — the runtime these plugins plug into
• Plugin development 101 — build your own
• Browse the directory