Official DSH plugins: built-in bundles & channels (Harness)

DeepSeek Harness official plugins come in two layers: built-in bundles and plugin packages. The bundles @deepseek-ai/dsh-base, dsh-web-app and dsh-headless form the running skeleton of every profile — the web and headless profiles auto-initialize on first use — while the LLM adapters dsh-llm-deepseek and dsh-llm-pi-ai handle model access. This guide walks through bundles, LLM plugins, official channels and the official-vs-community distinction in four steps.

Overview: the two-layer structure of official plugins

Official plugins split by role: bundles define "which form to run", LLM plugins define "which model to connect". The official repo organizes official capabilities into two kinds of packages: bundles under packages/bundle define the profile's form (web / headless tasks), and plugins under packages/llm handle model access (source). Understanding these two layers explains what official capabilities dsh loads at startup and makes it easy to tell them apart from community plugins. The bundles come first.

1. Official built-in bundles: the profile skeleton

Built-in bundles ship with the dsh install as config layers: dsh-base is the shared core, dsh-web-app is the browser form, dsh-headless is the UI-less task form — every profile is composed from them. A bundle is an npm package declaring dsh.bundle with an attached config patch layer (source). The three official built-ins (source):

How they relate: dsh --profile web boots the web form composed of base + web-app; dsh --profile headless "task" boots base + headless, runs one task, prints the answer and exits (source). To verify both built-in profiles yourself, just launch them:

# Boot the built-in web profile (the web form composed of base + web-app)
dsh --profile web

# Run a one-shot task with the built-in headless profile (prints and exits)
dsh --profile headless "Summarize this repository"

The web and headless profiles auto-initialize on first use from shipped templates; other profiles are created via dsh plugin. Built-in bundles always resolve from the dsh installation itself, while community plugins install into the profile's own node_modules.

2. Official plugin packages: LLM adapters

Official LLM plugins handle model access: dsh-llm-deepseek connects DeepSeek directly, dsh-llm-pi-ai goes through the multi-provider pi-ai adapter, supported by the service definition, token metering and retry policy. The official packages under packages/llm (source):

1. @deepseek-ai/dsh-llm-deepseek: the direct DeepSeek adapter, registering a provider route on ctx.llm — the default channel for the Web UI to reach the DeepSeek API.
2. @deepseek-ai/dsh-llm-pi-ai: the multi-provider pi-ai adapter, also registered on ctx.llm, for models covered by pi-ai.
3. @deepseek-ai/dsh-llm: the LLM service definition and shared streaming vocabulary — the base under both adapters.
4. @deepseek-ai/dsh-token-meter: per-session token measurement that listens to request events.
5. @deepseek-ai/dsh-llm-retry: provider-scoped retry policy that retries automatically on request errors.

In short, "which model to connect" is decided by the LLM adapter — switch providers by switching adapters without touching dsh itself, which is exactly what the everything-is-a-plugin architecture means.

3. Official channels: where official plugins come from

There are four official channels — the website, GitHub, npm and the docs — and official package names always carry the @deepseek-ai prefix. For official components, stick to these channels (source):

1. Website deepseek.com/harness: product introduction and download entry;
2. GitHub deepseek-ai/deepseek-harness: source, Releases and changelogs — official plugin packages live under the repo's packages directory;
3. npm @deepseek-ai/dsh: installing and upgrading the core; official packages are named @deepseek-ai/dsh-*;
4. Docs deepseek-harness.github.io: plugin development, packaging and installation tutorials.

Community plugins are concentrated in the dsh-plugin.org plugin center and the built-in market of DSH Plugin Hub (4,800+ listed), complementing the official channels.

4. Official vs community: how to tell them apart and choose

Judge whether a plugin is official by three things: whether deepseek-ai maintains it, whether it ships with the dsh install, and whether the npm name carries the @deepseek-ai prefix. In practice:

1. Check the source: every plugin in the plugin center marks its source and maintainer; official packages show deepseek-ai;
2. Check verification: verified means compatibility has been manually checked — official packages are reliable by default, and among community packages prefer verified ones;
3. Choose by need: pick official for model access and core forms; for UI enhancements, memory, tools and other extensions the community ecosystem is richer — browse by category in Settings → Plugin Center of DSH Plugin Hub first.

dsh-plugin-hub · Plugin Center

Notes on official plugins

In one sentence: official plugins manage form and models, community plugins manage capability extensions — check source and verification before installing. Three reminders:

1. Do not install built-ins manually: dsh-base / web-app / headless ship with the install and are referenced by profiles automatically — do not add them again from the plugin center.
2. Do not stack adapters: use one primary model provider at a time; mixing multiple adapters can cause route conflicts — switch models via the official docs config instead.
3. Trust the source for community packages: GitHub distributions may lack build output, so prefer the npm build or check the source tag in DSH Plugin Hub before installing.

Sources: deepseek-ai/deepseek-harness - packages/bundle, packages/llm, DeepSeek Harness Docs - Package and Publish Plugins