DSH plugin profiles and bundles in DeepSeek Harness

DeepSeek Harness records a named assembly in a profile, which holds cordis.patch.yml; a bundle is the distribution format of "Cordis config entries + mount code", declared through dsh.bundle in package.json (source). The two words are often mixed up: one is the list of "which layers to install", the other is the format for "how a layer is packaged and distributed". Tell them apart and you can read "what actually loaded at startup" and "which file to edit for a config change". This piece covers only what these two concepts are and how they relate; how to create a profile, see how to create a custom DeepSeek Harness profile, how to publish a bundle, see how to ship a dsh plugin bundle, and the whole tree, see DeepSeek Harness architecture explained.

What a DeepSeek Harness profile is: a name plus an assembly

A DeepSeek Harness profile is one named assembly that records which DSH plugin layers to load at startup and their individual overrides; it lives in the Harness home and contains a cordis.patch.yml (source). Unpack the three things in the name:

1. "Named" means one profile per name: names such as web and headless each correspond to a definite list of layers. Startup picks one by name, so "switching profile" is really switching a list — hence switching a tree.
2. "Assembly" means it implements no capability: a profile contains no tools and no model adapter, only a list and overrides; the layers it mounts are the ones that do the work.
3. "Persistent" means it lives on disk: a profile sits in the Harness home, so the changes you make and plugins you install are still there next launch — which is why it is not the same thing as a one-off command argument.

Once this is clear, several things follow: why does the same dsh behave differently under different profiles? Because their lists differ. Why does switching profile feel like switching software? Because you switched how the whole plugin tree is assembled.

What a profile holds: an override list and a dependency record

The core of a profile is an override list — cordis.patch.yml; it also holds the assembly's dependency record, kept in the profile directory's package.json and node_modules (source). The two kinds of content cover different things:

1. cordis.patch.yml handles overrides: it does not redefine plugins, only patches and tunes already-declared entries — so to adjust the behaviour of a profile it is usually enough to edit here, without touching the source of any DSH plugin.
2. The dependency record tracks "what was installed": plugins you add to this profile stay as dependencies in the profile directory, and that is exactly what dsh plugin list reports — not the repository's devDependencies.
3. Together they decide the tree: the list (with overrides) decides which layers load and how each is configured; the dependency record decides where those layers' content comes from and which versions they run on.
4. They can be derived: web and headless are starting points, not ceilings — you can derive your own profile on top of them and preload favourite plugins and settings.

To build your own assembly by hand, follow how to create a custom DeepSeek Harness profile; how the concepts relate is in five concepts to know before installing plugins.

What a bundle is: config entries plus mount code

A bundle is a DeepSeek Harness distribution format whose content is "Cordis config entries + mount code", declaring its identity through the dsh.bundle field in package.json (source). Four sentences separate it from an ordinary plugin:

1. An ordinary DSH plugin provides capability: it implements concrete tools, commands or services and, once mounted by a profile, adds a capability layer to the tree; it cares about "what to do".
2. A bundle provides one assembled layer: it packages a group of config and mounting logic, caring about "how to put these capabilities together and with which parameters to mount them".
3. The declaration differs: a bundle declares its identity with package.json's dsh.bundle; a package without that field is just an ordinary dependency and does not activate as a whole layer. Adjacent to it is the dsh.profile field, which ties a package to a specific profile.
4. A bundle can organise several plugins: capabilities come from plugins, layer organisation comes from bundles, and the two jobs differ — which is why "the plugin is installed" does not mean "it is active", since it also depends on whether it entered the list as a bundle.

To add a layer to a profile, find a ready-made package under Settings → Plugin Market, which is DSH Plugin Hub; for how to publish a bundle, see how to ship a dsh plugin bundle.

How profile and bundle work together

In DeepSeek Harness the two cooperate as "the profile names them, the bundle supplies them": the profile's list decides which layers are wanted, and bundles decide how those layers' content is organised and mounted. Trace it as a sequence:

1. First there is a profile: you pick or create one, and it gives the list of entries to mount.
2. A bundle extends the list: installing a package that declares dsh.bundle appends it to the profile's bundle list, joining startup as a whole layer.
3. The override list fine-tunes: before startup, cordis.patch.yml overrides each entry, finally fixing each layer's actual parameters.
4. Together they grow the tree: only after the three stack do you get the tree you see at runtime — which explains why "installing a plugin" involves the profile, the bundle and the override list at once.

Profile templates shipped with DeepSeek Harness

DeepSeek Harness ships several profile templates, commonly web, headless, sdk and sdk-minimal, plus acp (source). Their scenarios:

1. web: includes the graphical UI, for everyday interactive use; all Web GUI layers live in this tree.
2. headless: no UI, for scripts and automation; it loads no UI-related layers, so startup is lighter.
3. sdk: for embedding and calling from a program, treating dsh as a programmable runtime.
4. sdk-minimal: a leaner embed, for enabling capabilities on demand instead of pulling up every layer at once.
5. acp: a run mode aimed at protocol access.
6. Templates can be derived: these are starting points, not ceilings; deriving your own profile on top of them is the usual way to preload favourite plugins and settings.

Notes on profiles and bundles

Treat the profile as an "assembly list" and the bundle as a "reusable layer" and the two concepts will not blur.

1. profile ≠ plugin: a profile is a list with overrides and implements no capability by itself.
2. Check cordis.patch.yml first for behaviour: most tuning happens at the override layer, without editing plugin source.
3. bundle ≠ feature package: it organises config and mounting; the plugins it brings in do the work.
4. dsh.bundle decides identity: without that field a package is only an ordinary dependency and does not activate as a whole layer.
5. Read dependencies at the profile layer: the repository's devDependencies are irrelevant to you; the record in the profile directory is what takes effect.
6. Templates can be derived: web / headless / sdk / sdk-minimal / acp are the starting points that ship with the release.
7. Installing a plugin is adding an entry: if you cannot tell where a plugin went, look at the current profile's list and dependency record.

Source: DeepSeek Harness docs - architecture overview, docs - Python SDK guide.