DSH plugin config-catalog: DeepSeek Harness plugin settings

The DeepSeek Harness plugin config catalog (config-catalog) is generated from source by script and lists, per loadable harness package, that package's config declaration verbatim; every config: block can be set from a cordis.yml entry, and each entry is tagged with inject, refs, and source (source). This article explains what it is, how to read it, and which fields you can and cannot configure.

What the DeepSeek Harness config catalog is: config declarations by package

config-catalog is a deployment-oriented reference: for every loadable harness package it lists, verbatim, the config declaration accepted by that package's apply function or service constructor (including JSDoc), plus all referenced types (source). Key points:

1. It is generated from source — the file comes from scripts/gen-config-catalog.ts, and pnpm run verify-config-catalog checks its freshness. Expected: read it only; never edit it by hand.
2. The single config entry point is cordis.yml — every config: block can be set from a cordis.yml entry. Expected: find the package name, then write a config: block in the corresponding profile's config.
3. Scope is the harness layer — the catalog is limited to packages/; the config tree may also load vendored cordis plugins (such as the console logger). Expected: if you cannot find a vendored plugin here, check its upstream docs.
4. Three references, three jobs — model-facing tool schemas live in the tool catalog, the wiring plugin authors rely on lives in each subsystem page's cordis-surface section, and this catalog only lists config declarations. Expected: do not mix up their purposes.

Reading an entry: inject, refs, and source

Each package entry is tagged with three markers; once you read all three you know who the plugin depends on and where else to look for types (source). One by one:

1. inject — lists the service keys the plugin injects. Expected: it reminds you that the plugin's cordis.yml tree must also load the providers for those services, or the plugin will not start.
2. refs — lists types the declaration references but does not paste here. Expected: follow it when you need the full definition.
3. source — links to the file that declares this config. Expected: reading the source is the surest way to confirm field semantics or defaults.

Which DSH plugin fields you can and cannot configure

What is pasted is the plugin's full declared config type — fields the runtime schema deliberately excludes are runtime-only seams (their JSDoc says so) and cannot be set through cordis.yml (source). How to tell:

1. Check for a runtime seam first — excluded fields carry their own note. Expected: writing such a field into cordis.yml has no effect anyway.
2. Then land it with real fields — take DeepSeek session logging: you can turn it off with session-log-deepseek.enabled: false in a profile patch (source). Expected: the config only takes effect when the field name matches both the catalog and the source.
3. Verify by profile after editing — confirm you wrote it into the profile actually in use. Expected: trying another profile once rules out "wrote it in the wrong layer".

To find ready-made plugins and see what the community configures, start on DSH Plugin Hub, then check the config fields a plugin exposes here.

Notes and common questions

1. Do not hand-edit generated files: config-catalog is a build artifact, and changes are flagged as stale by verification.
2. Unsatisfied inject fails startup: if the service providers are not loaded in the same config tree, the plugin cannot inject.
3. Schema-excluded fields cannot be set: do not try to bypass a runtime seam through cordis.yml.
4. A field-level catalog is not an override rule: to learn how multiple patches merge and which wins, see Change DeepSeek Harness plugin config.
5. Want to know where config files live: see Where DeepSeek Harness config files live.

Sources: Plugin config catalog (official docs), Python SDK (official docs)