Files
deepseek-harness/packages/client/ui-settings-plugins

description, kind
description kind
Plugins settings section for the dsh web client: feature-owned tabs, the configurable host-plane plugin cards, and the settings.plugin.item extension point. package-reference

@deepseek-ai/dsh-client-ui-settings-plugins

English | 中文

Summary

dsh-client-ui-settings-plugins is the Plugins settings section of the dsh web client: users edit host-plane plugin configuration on its Plugin configuration tab, and feature plugins contribute their own pages through settings.plugins.tab. This package's own tab shows one expandable card per Host plugin whose configuration a user owns: a card shows the plugin's name and what it governs, and expanding it reveals hand-written controls bound to that plugin's settings namespace, each field marking whether the user overrode it and offering a reset back to the value the deployment composed. Cards stage edits locally and write only on save, with every write fenced by the namespace revision the form read.

Table of Contents


Use this package

Open the Plugins section in Settings and select the Plugin configuration tab to edit the host-plane plugins this deployment composes. The cards this package ships cover the shell executor (bash), the agent loop's tool-call parallelism (agent-loop), and the DeepSeek search provider (web-search-deepseek).

What appears here

The tab reads which settings namespaces the Host serves and dispatches one slot key per namespace, so what renders is the intersection of two ledgers: the namespaces a live Host plugin registered, and the cards registered under those keys. A served namespace no card claims renders nothing, and a card whose namespace this deployment does not serve is never dispatched. The empty line waits for the Host's first answer, so an unanswered read never reads as "this deployment configures no plugin".

Editing and saving

A card stages what the user types and writes it only when they save. Each control renders staged text, so what is on screen is exactly what a save would store; Discard drops the drafts, and a card holding unsaved edits says so on its header even while collapsed. A reset stages the composed default rather than writing immediately, and a draft the field does not accept blocks the save instead of being dropped. The Host is the only authority on whether a value was accepted — the card reads the section back afterwards and reports a save that did not land, keeping those drafts for the user to correct.

Secret-role fields

A key control starts blank, reports only whether one is configured, and writes through the credentials domain rather than the settings section; a blank draft writes nothing and keeps the stored key.


Understand the implementation

Implementation internals — click to expand

The section is one extension point and one dispatch rule: feature plugins own their cards; the tab pairs served namespaces with registered cards by slot key.

The tab extension point

The section declares settings.plugins.tab, a root list slot whose labels become ordered tabs; a tab stays mounted after its first selection so local drafts and read-only snapshots survive tab switches. The package registers its own configurable contribution, which declares the nested settings.plugin.item slot — keyed on the settings namespace a card edits. A plugin that ships a browser half registers its own card under its own namespace and owns every part of it: chrome, controls, and copy. Tabs follow the contribution's order; cards follow registration order.

The write path

Saving writes each staged field through the client settings scope, which fences every write with the namespace revision it read, so a form that has drifted from the document is refused rather than overwriting a concurrent change. A field's presence in the raw user layer — not its value — is what marks it overridden; a reset clears that field so it re-inherits the composition layer. Secret-role fields never ride a response; the card re-reads on the forwarded credentials/reference-updated event for the reference it watches.


Further Exploration

These pages cover the settings base, the inventory tab, and the durable seams behind the cards.


Model Experience

None, as the package is a browser-side settings surface that registers no model surface.

KV Cache effect

None; this package neither assembles nor sends a provider request.

Known Limitations and Deferred Work

These limits define which plugins appear and how fresh the list is; they are current package constraints.

  • Only host-plane plugins appear — a plugin an agent preset mounts carries its configuration inline in that preset's agent.cordis.yml and cannot register a settings namespace at all, so this section lists nothing for it. Editing those values remains the preset editor's job.
  • A card still needs a browser bundle — the browser half must be a dsh.client package built in the client module system's lazy-CJS factory format, and the clientBundle preset that emits it lives in ../../../packages/client/tsdown.client.ts rather than a published package, so a plugin outside this repository has to reproduce that build itself.
  • The served namespaces re-read on two signals only — the wire announces settings-document commits and connection resets, not registrations, so a namespace whose owner registers after the tab's read joins the list on the next document commit or reconnect.
  • The shell card follows the composed executor — the POSIX and PowerShell executor families share the bash namespace because a host composes exactly one of them, so the served schema differs by platform (PowerShell adds pwshPath) even though the card edits the same two fields on both.

Dev Note

Working context for maintainers — click to expand

None.