The shared capability registry and lifecycle scope used by plugins.
Documentation
DeepSeek Harness Plugin Guide
Learn how the Harness plugin system fits together, choose the right extension surface, review community code, and move from discovery to a reproducible installation.
What are DeepSeek Harness plugins?
Composable capabilities inside the Harness runtime
DeepSeek Harness is an open-source agent harness from DeepSeek AI. Its official architecture treats components as plugins: a plugin can register services, tools, model providers, session behavior, user-interface elements, runtime hooks, or other capabilities through the shared context.
A repository in this directory is considered a DSH plugin when the community registry supplies a Harness install record and points to source intended for the plugin system. A package that only calls the DeepSeek API, integrates with another agent framework, or happens to include “DeepSeek” in its name belongs to a different ecosystem.
The official project currently labels itself a developer preview and warns that compatibility-breaking changes are expected. Record the Harness revision, plugin revision, profile, and operating system you actually test.
Core architecture
Context, reversible effects, profiles, and bundles
The Harness uses a Cordis context as the plugin boundary. A basic TypeScript plugin exports an apply(ctx) function. Registrations made through the context are scoped to the plugin lifecycle, so the runtime can clean them up when the plugin is disposed.
import type { Context } from '@deepseek-ai/dsh'
export function apply(ctx: Context) {
ctx.effect(() => {
// Start a resource or subscribe to an event.
return () => {
// Release that resource when the plugin stops.
}
})
}Explicit setup and cleanup for timers, listeners, processes, and other resources.
Named runtime configurations such as the Web profile, stored through dsh.profile.
Installable groups of plugin configuration published through a dsh.bundle entry.
Plugins can declare required services through injection and configuration through a typed Config shape plus a Schemastery schema. The official guide recommends validating configuration and failing loudly when required values are invalid.
Plugins and MCP
Choose the extension boundary that matches the job
Runs inside DSH
- Can integrate with profiles, sessions, models, Web UI, tools, and lifecycle services.
- Can change local runtime behavior and may carry broad permissions.
- Uses the Harness plugin contracts and follows their preview-version compatibility.
Exposes a portable protocol surface
- Usually offers tools, resources, or prompts to compatible clients.
- Can run as a separate process or remote service.
- Fits capabilities that should work across more than one MCP client.
The two can be combined. A Harness plugin may manage an MCP connection or expose client-specific controls around a portable MCP service. Prefer the smallest trust boundary that can satisfy the task, especially when filesystem access, shell execution, browser control, or credentials are involved.
When to use plugins
Start from the capability and its required access
Add a deterministic tool, vision workflow, browser bridge, reusable skill, or provider adapter.
Browse agent capabilitiesAdd composer behavior, file navigation, a side panel, visualization, themes, or other Web UI surfaces.
Browse workspace pluginsCoordinate sessions, durable memory, schedules, agent teams, notifications, or background activity.
Browse workflow pluginsInspect manifests, audit context, expose lifecycle hooks, or build profile and developer tooling.
Browse runtime pluginsA prompt is enough, an existing built-in already covers the task, a standalone command has a clearer boundary, or a portable MCP service meets the same requirement with less runtime access.
Getting started
From a clean Harness profile to one reviewed plugin
- 1Start the official Web experience
Follow the current repository prerequisites, then run the command documented by DeepSeek AI.
npx @deepseek-ai/dsh web - 2Configure a model and workspace
In DSH Web, configure a model under Settings → Models and choose the workspace the agent may access.
- 3Open the plugin source
Match the GitHub owner, repository, package, bundle manifest, profile instructions, license, recent activity, and open compatibility reports.
- 4Review the recorded install command
A common community-registry form is shown below. Use the exact source and version recommended by the maintainer.
dsh plugin --profile web add github:OWNER/REPOSITORY - 5Verify the narrow outcome
Test one unfamiliar plugin at a time, inspect logs and network access, and confirm a recovery or removal path before relying on it.
Review and publish
Keep source identity, runtime effects, and recovery visible
Owner, repository, package, install reference, version or commit, and license match.
Harness revision, profile, operating system, required services, and configuration are recorded.
Filesystem writes, shell commands, network destinations, secrets, browser permissions, and long-running resources are understood.
Disable, uninstall, cleanup, profile restoration, and data-retention behavior are testable.
The repository documents its bundle, usage, configuration schema, license, and support expectations.
Add the public dsh-plugin GitHub topic and follow the community registry contribution process.
This directory is an independent discovery surface. Inclusion, stars, and recent activity do not constitute a security audit, official endorsement, or a promise of compatibility.