How to Install DeepSeek Harness Plugins

Prerequisites

Before installing plugins, make sure you have DSH installed and running:

The web launcher is a useful first check because it confirms that the harness can start before you add another package. If this command fails, fix the base DSH setup first; a plugin cannot repair a missing runtime or an invalid Node environment.

Choose the profile you want to evaluate before you install anything. The examples below use `web`, but a team might use `default`, `local-memory`, or another descriptive name. The profile in the install command must match the profile in the launch command.

Keep the terminal that starts DSH available while you test. Startup output is often the fastest way to distinguish a bundle problem from a provider credential problem, a blocked build script, or a profile mismatch.

If you are working in a repository, check its Node version and package manager before launching. Reproducing the expected toolchain prevents a shell-level mismatch from being mistaken for a plugin defect.

You should see the DSH web interface at localhost:3000.

Install from npm

Most plugins are distributed as npm packages with a dsh.bundle manifest. Before running the command, read the package page and repository README so you know what the plugin changes and which permissions it expects.

The `--profile` flag makes the destination explicit. Installing into `web` and launching `default` can look like a failed install even though the package was written successfully to another profile. Treat the profile name as part of the install identity, not as an optional display setting.

A successful command means that DSH fetched the package and accepted its bundle metadata. It does not mean that every runtime dependency is healthy. Restart the target profile, look for the plugin name in the startup output, and run one small workflow before you rely on the capability in a larger task.

This downloads the package, registers its bundle patch, and activates the plugin on next launch.

Install from GitHub

You can also install directly from a GitHub repository. This is useful when a plugin is not published to npm yet, or when you need to evaluate a repository version before a release is cut.

Read the repository's package scripts, lockfile, license, and recent commits before installing. A GitHub URL can point to changing source, so pin a commit or release tag when you need the same code to be loaded again by another person or environment.

GitHub installation is a wider trust decision than reading a README. Prepare scripts may run during dependency setup, and the resulting package may request network access or credentials at startup. Keep this experiment in a disposable profile and remove it if the requested access does not match the capability you need.

Verify Installation

After installing, restart DSH and check the plugin loaded. Restarting matters because the profile reads its bundle configuration during startup; leaving an existing process open can make a valid installation look inactive.

Look for the package name, bundle entry point, and an `[ACTIVE]` or equivalent success marker in the startup log. If the output names the package but reports a dependency error, the harness found the bundle and the next investigation belongs to the plugin's runtime requirements.

Then exercise the smallest real workflow that the plugin is meant to support. For a memory plugin, retrieve a note you just stored; for a tool plugin, call the tool with a harmless input; for a provider adapter, make a short request. Record the result, latency, and any permission prompt so an upgrade can be compared with this baseline.

Look for your plugin name in the startup log. If it shows [ACTIVE], the plugin is loaded and running.

Common Problems

Most installation failures fall into one of three boundaries: the package is not a valid bundle, the package is installed into a different profile, or a build/runtime permission is missing. Check those boundaries in that order before changing unrelated agent settings.

Capture the exact startup message when you troubleshoot. A short error copied from the terminal is more useful than a general statement that the plugin is missing, and it helps the package maintainer reproduce the same path without access to your profile.

• Plugin not loading? — Check that the package has a valid dsh.bundle field in package.json, then inspect the entry point named by the manifest. A package can download correctly and still be skipped if the bundle contract is incomplete.
• Build script blocked? — Run with the --allow-builds flag only after reviewing the package scripts and source. If the plugin does not need a native dependency, prefer an install that does not expand build permissions.
• Wrong profile? — Make sure you installed into the same profile you're launching. Compare the literal profile value in both commands and remove the package from the wrong profile so future tests stay unambiguous.

Next Steps

Once the plugin passes one real workflow, write down the profile, package source, version or commit, permissions, and verification result. That small record turns a one-off experiment into a reproducible setup and gives you a rollback point when the package changes.

If you are still deciding which capability belongs in the runtime, read the guide that explains what a DeepSeek Harness plugin is. If the change is mostly a procedure or a shared external service, compare Plugins, Skills, and MCP before installing another package.

The catalog can help you find candidates by category and inspect bundle status, license, and maintenance signals. Treat those signals as a starting point, then review the repository and test the plugin with the least sensitive data that still proves the workflow.