DeepSeek Harness plugins: 3 sources and first 5 installs

The answer to deepseek harness plugins is not a list. It is three sources plus a verification routine: official built-in bundles, the built-in DSH Plugin Hub, and GitHub or npm. Decide which capability you need, then choose the source.

Overview: split the word plugin first

People searching deepseek harness plugins usually share one problem: they know plugins exist but not where to start. Split the question into three parts: the objects, the sources, and the verification commands.

A DSH plugin is a TypeScript module that exports an apply function. The framework calls apply with ctx, and the plugin registers commands, tools, UI components, or services on that context (source). Installing a plugin therefore means attaching registration logic to a running environment, not installing a separate application.

A profile decides where that logic attaches. web, headless, and desktop keep independent dependency trees and settings. The same plugin installed into two profiles becomes two instances that do not affect each other. This is the detail English searchers miss most often: they install in the desktop app and then look for the plugin in the terminal.

A plugin package is only the distribution form. It can be an npm package or a GitHub repository reference; a Hub entry is a presentation layer over those sources. Once you see that relationship, duplicate names stop being confusing: check the source and the package name before the display name.

Three sources: built-in, Hub, GitHub and npm

There are only three kinds of sources, and the difference is who maintains them and how you discover them.

Official bundles solve baseline capability. They move with the core version and upgrade together, so compatibility is less of a question. The trade-off is coverage: they only include what the vendor considers generally useful.

DSH Plugin Hub solves discovery. The entry is under Settings, Plugin Market, where you can browse by category, search, read version and verification status, and install in one click (source). Hub is a community project and is not affiliated with DeepSeek AI, but it puts source, compatible version, and verification status on the same card.

GitHub and npm solve provenance. The install command on a Hub detail page points at one of these two: github: installs a repository, a package name installs from npm. To verify where a plugin really comes from, read the source label instead of the display name.

The three are not exclusive. Hub is the discovery layer, GitHub and npm are the distribution layer, and official bundles are the stability layer. The normal path is Hub to find, source to confirm, and the detail-page command to install.

First five plugins: by frequency, not popularity

Do not install ten plugins on day one. Install one with an observable effect, prove the chain works, then add the next.

1. dsh-memory for cross-session recall. After installation, a new session can read preferences and conclusions from earlier work. It is easy to verify: ask about a project you discussed before and see whether the answer includes it.
2. dsh-browser for a shared real browser. It lets the agent drive a visible browser that you can take over. Install it, open a local page, and confirm you can take control before moving on.
3. dsh-better-sidebar for a right-hand workbench. It turns the right panel into file editing, terminal, Git, and subagent task views. It is sensitive to version matching, so check the compatible version on the Hub card first.
4. dsh-context for a context dashboard. It shows statistics, trends, events, and file activity, which helps explain sudden context growth. It is not required, but useful for long-running use.
5. dsh-cost-meter for session spend. It shows a cost capsule and bucketed billing in the stats row. You must fill in prices that match your model provider; defaults may not.

The ordering principle is verifiability; do not use a must-install list as a substitute for judgment. Memory and browser show an effect immediately; the workbench and dashboard are visual; cost needs a conversation to produce numbers. A list that works in someone else's profile may fail in yours because of version, platform, or permissions. The Hub card's verification status and compatible version are closer to your reality.

Before installing: two commands

Confirm two things first: the CLI runs, and the target profile is initialized.

1. Run dsh --version. A version number means the CLI is available; command not found means fix the installation before touching plugins.
2. Run dsh plugin --profile web list. An empty list is fine, as long as the command succeeds and shows the profile's plugin state.
3. If you are installing for the desktop app, replace web with the actual profile name; dsh --dump-config shows the profiles in use.

Get the commands working before discussing installation. More than half of failed plugin installs are really a broken CLI or a wrong profile.

After installing: three signals

A plugin is really installed when three signals are true: it is listed, it is in the config tree, and the UI shows an entry.

1. List signal: dsh plugin --profile web list contains the package.
2. Config signal: dsh --dump-config contains the section the plugin registers.
3. UI signal: after a restart, the entry, command, or panel appears.

All three signals must pass. An install success toast only means the package was downloaded and processed. It does not prove registration.

Check from the bottom up. If the list is correct but the config tree is missing the section, suspect a broken package or a load failure. If both are correct but the UI is empty, restart first, then read the system log.

Five reasons a plugin appears installed but does nothing

Five causes cover most cases, ordered by frequency.

1. Wrong profile. You installed into web but looked in the desktop app. Run list in both profiles to see where the package landed.
2. Version mismatch. The plugin's compatible range does not include your core version, so loading is skipped. Compare the Hub card with dsh --version.
3. No restart or failed hot reload. A newly installed plugin is not injected into an already running UI. Exit fully and start again.
4. Wrong same-name source. The market has several entries with the same display name. Compare package name and owner, not the display name.
5. Blocked dependency or build script. The package downloaded but its build output is incomplete. Check the install stage in system logs.

Investigate from the bottom up: load stage in the log, then config tree, then list, and only then the plugin itself. Reverse the order and you will reinstall in the wrong direction.

Choosing a source: a scenario table

Source choice is simple once you name the goal: stability, discovery, or source code.

The everyday combination is Hub to discover, npm to install. Copy the command from the detail page, then add a version number when you need reproducibility.

Return to the source when something breaks. If behavior is wrong, read the real repository's issues; the Hub is an index, not the implementation. Likewise, do not compare a GitHub-sourced plugin with a same-name npm package and assume they are the same project.

Next steps

Install one, verify one, then expand. If the core is not installed yet, read How to install DeepSeek Harness. Once it runs, open DSH Plugin Hub, install your first plugin, and verify it with the three signals before adding another.

To go deeper, read dsh plugins vs dsh plugin to understand the search terms, or How many DeepSeek Harness plugins are there to see the three counting methods.

Sources: DeepSeek Harness docs - Your first plugin, dshplugin/dsh-plugin-hub, dsh CLI README, DSH Plugin Hub plugin page