DeepSeek Harness Configuration Guide: Profiles, Patches & Agent Presets (2026)

Everything is a plugin tree

A running dsh is not a binary with features bolted on. It is a plugin tree — a Cordis plugin system assembled at startup from layers of configuration. Every capability (tools, model adapters, storage, sandboxes, the UI, the main loop) is a plugin in that tree, and the configuration layers decide which plugins exist, in which order.

That is the whole mental model. The rest of this guide unpacks the layers.

The layers, from base to top

Configuration stacks in a fixed order, and upper layers override lower ones:

┌─────────────────────────────┐
│  patches      (your overrides)   ← wins
├─────────────────────────────┤
│  profiles     (your named assemblies)
├─────────────────────────────┤
│  bundles      (official plugin sets)
└─────────────────────────────┘

• Bundles — official sets of plugins shipped together. The default experience you get on first launch is a bundle.
• Profiles — named assemblies on your machine. A profile says "load these bundles and plugins, with these settings". You can keep several and switch between them.
• Patches — your own override layer. A patch can target any single plugin entry and replace it, without touching the profile it came from.

Because every layer is just configuration, sharing a setup is sharing the files. Copying a profile or patch is how someone hands you "their dsh".

The patch layer: a dressing system for your agent

The built-in patch layer is the part that feels least like other agents. Think of it as a dressing system — you decide what capabilities the agent wears, and under what conditions:

• Mount local agents as sub-agents. Your machine's Codex and Claude Code can be registered as sub-agents the harness delegates to, rather than competitors it replaces.
• Wire in capabilities. Install plugins that add tools, integrate external services, adjust run permissions, or turn on full-text search.
• Replace the UI. Interface modules are plugins too — skins, panels and even whole UI components can be swapped through a patch.
• Make rules conditional. Rules are JavaScript expressions, so a capability can apply only where you want it: a specific repo, a file type, a time of day.

The patch targets a single plugin entry, so each of these is an override you can add, inspect and remove without touching the profile below it.

Why "installing a plugin" is a config edit

There is no central package manager in the "install and forget" sense. Installing a plugin means adding an entry to your profile or patch layer; the plugin repository's README documents the exact line. On next start the plugin joins the tree; on removal, everything it registered is revoked — registration must be a reversible side effect, which is why a bad plugin can't leave residue behind (see the plugin development guide).

The built-in plugin manager, and what it does not do

The 0.1.6 alpha line (alpha.2, published 2026-09-17) adds a plugin management page inside dsh: install a plugin, edit its configuration, and enable or disable plugins at runtime — no restart needed for that toggle. The same release moved plugin dependency resolution to runtime resolution and supports runtime unloading, and the release notes explicitly ask plugin authors to re-check their load and unload logic. Stable (latest on npm) is still 0.1.5-rc.2, so if you do not see the page, you are not on the alpha channel.

Two things worth separating before you rely on it:

• The built-in page manages what you already have installed — the plugin set in the profile you are running, and each plugin's options. That is exactly the layer this page has been describing: it is a friendlier front end for the same profile and patch state.
• It does not answer what to install. There is no ranking across the ecosystem, no per-scenario grouping, no "who else uses this with that" — and that question is what this directory is for. Start at Explore Collections or Top 10 Best Plugins, copy the install command, and let the built-in page handle the on/off and options afterwards.

One consequence of runtime resolution: a plugin that loads fine today can fail after a harness update if its author has not adapted yet. If that happens, Troubleshooting §8 covers pinning the version and rolling back.

Where dsh puts things on disk

Because an "install" is a config edit, almost nothing gets copied into a hidden system folder. What an install really does is write a dependency entry into a profile — and each profile is a plain directory you can open, read and back up:

Two habits follow from this layout. When a plugin "isn't there", list the profile before you go digging through the filesystem: dsh plugin --profile web list shows exactly which dependency entries the profile has and which directory it read them from. And backing up — or handing someone — an environment means copying files: a profile directory plus a patch file is the whole setup. The same paths are what you remove for a clean slate (see uninstalling plugins & wiping ~/.dsh).

Archiving and cleaning up sessions

Sessions are files under the harness home (~/.dsh, or the DSH_HOME override), and people tend to conflate three different actions on them:

• Archive is a visibility change: the session drops out of the active list but stays on disk. The rough edge is real — discussion #8344 asks how to delete archived sessions or show them in one place, and no per-session delete command is officially documented yet.
• Export is the "archive" the official docs write down: session-log export carries a ZIP-compression archive policy (config catalog). Want a portable copy of a conversation? Export it before you clean anything.
• Cleanup means removing session files under the harness home — with the same rule as everything else on this page: back up first. Deleting ~/.dsh is the full reset (the uninstall guide walks it), and before harness upgrades, community multi-instance managers such as dsh-lanes back up conversations per install so a failed upgrade cannot take your history down with it.

The dsh command, at a glance

The dsh command is the entry point for everything above — and since 0.2.0-rc.2 it is also a first-class desktop feature: the macOS and Windows desktop apps carry a "Manage dsh command" menu-bar item that installs and manages the command for you, plugins included, without a separate Node.js or pnpm installation. If your terminal says dsh: command not found, that menu item is now the official fix (see also Troubleshooting §11).

For everyone else, the everyday vocabulary is short:

Two habits worth keeping: check dsh --version before every diagnosis, and match the --profile flag you install with to the one you launch with — the single most common "my plugin is gone" cause. The troubleshooting guide collects the rest. The printable version — every command, flag and mode grouped for the desk — lives in the dsh CLI cheat sheet.

Agent presets: the shape of one session

The mode selector at the top of the UI picks an Agent Preset — a complete definition of the agent in this session:

• which tools it has,
• its system prompt,
• which skills are loaded,
• its sub-agent and workflow setup.

A preset is not a plugin list plus a prompt; it is the whole contract the session runs under. That's why a session locks its preset once it has content — switching mid-session would make the tool calls already in history uninterpretable.

The four built-in presets:

Making your own preset

The Creation mode is the sanctioned way to design a new preset: describe what you want ("a read-only code reviewer that never edits files and answers in Chinese"), and the harness inspects the live runtime, experiments with plugins in memory, drafts the config, mounts it and saves it for reuse.

Want the hands-on version? The frame-verified walkthrough Custom DeepSeek Harness agent presets runs the whole flow — from Creator mode to a saved, working preset — with screenshots at every step.

Two cautions from the docs worth repeating:

• Creation mode executes model-written code against the runtime — trust it like shell access.
• Presets are config, so review what it saved before making it your default.

When to stop configuring

The pleasant default is: run Standard, change almost nothing. Reach for profiles and patches when you repeat the same setup (a team shares one profile), when you want a fixed toolbox for one job, or when you want to swap one component (a different model adapter, a stricter approval policy). The upper layers exist so you can override one thing without forking everything.

Keep exploring

• Top 10 Best Plugins & Starter Packs — One-click commands for popular scenarios
• 12 Must-Have Plugins Guide
• Explore Curated Collections
• Installing Plugins Safely
• Uninstall plugins & clean up — remove one plugin, uninstall the harness, or wipe ~/.dsh
• Sandboxes, approvals & secrets — the safety model these layers plug into
• Quickstart: run dsh in 5 minutes
• The dsh plugins ecosystem