DSH plugin client modules: how DeepSeek Harness loads UI

dsh-client-modules is the Node half of DeepSeek Harness's client module system, and ctx.clientModules is its registry: it scans packages that declare dsh.client, composes the window.__DSH_BOOT__ entry graph, and serves combo scripts under /plugins (source). A plugin can do more than add model capabilities — it can add UI parts: a plugin with a settings card, a panel or a custom view has a back end handling data and a front end handling presentation, and this client module mechanism is what joins the two halves. This piece covers how it discovers, composes and loads; writing a plugin with UI is in how to build a UI plugin, and the layer map is in DeepSeek Harness architecture.

Why a plugin has a front-end part

A DSH plugin can carry both a back end and a front end: the back end registers capabilities, the front end provides UI, and delivering that front end into the browser is exactly why the client module system exists (source). Break the need apart:

1. UI is part of plugin capability: settings cards, status panels and custom views all need front-end code and cannot be registered from the back end alone.
2. The browser does not understand Node packages: the back end lives in the Node world and the page in the browser world, so someone must organise which front-end modules to load.
3. Loading relations should not scatter: if every plugin agreed its own loading path, the page would need bespoke logic per plugin; central management keeps it extensible.
4. UI should not burden headless scenarios: not every run mode needs a UI, so this mechanism must be optional rather than part of the trunk.

What the DeepSeek Harness client module system is

dsh-client-modules is the Node half of the client module system in DeepSeek Harness, and ctx.clientModules is the registry that manages it (source). Three points:

1. It bridges front end and back end: the Node half discovers and organises, the browser half actually loads; the two meet through one composed result so neither needs the other's details.
2. The registry manages it centrally: which packages have a front end and what each entry is are held by ctx.clientModules; declarations are collected there and the loading relations are generated from there.
3. It is not a trunk capability: it serves the Web GUI, and run modes without a UI do not depend on it — so its loading or failure affects the UI, not the conversation chain itself.

How front-end modules are discovered and composed

The client module system scans packages that declare dsh.client and composes their entries into the window.__DSH_BOOT__ entry graph (source). From discovery to loading:

1. Scan declarations: only a DSH plugin marked with dsh.client is treated as having a front end; a package without the declaration does not enter this flow even if it is a complete plugin.
2. Compose the entry graph: the front-end entries of those packages are gathered into one startup graph written into window.__DSH_BOOT__ — this decides which front-end modules the page pulls up at startup.
3. The page loads by the graph: from that graph the browser knows which modules to request, fetches them and mounts them, so the UI parts appear.

The entry graph and window.DSH_BOOT

window.__DSH_BOOT__ is the browser-side entry object carrying front-end startup information in DeepSeek Harness, into which the client module system composes the entry graph of packages declaring dsh.client (source). Three points:

1. It is the hand-off between two worlds: the Node half writes "what to load" into it and the browser half reads it out, so the hand-off happens on an object rather than a pile of conventions.
2. The entry graph is ordered: front-end modules have order and dependencies, and a graph gives loading order a basis instead of leaving it to chance.
3. Start UI troubleshooting here: when a plugin's UI part does not appear, first check whether it entered this entry graph — that immediately separates "the declaration did not take effect" from "it loaded and then errored".

How scripts are served: /plugins and combos

DeepSeek Harness serves front-end module scripts as combos under /plugins, with the loading relations concentrated on the client module system side (source). Two points:

1. Served by combination: the browser takes scripts by the composed result rather than agreeing a path per plugin; the path convention converges under /plugins, so adding a plugin does not require changing page-side loading logic. dsh-host-webserver is one of its consumers.
2. An optional capability of the Web GUI stack: it is not on the agent loop trunk, so headless scenarios can skip it entirely — which is why "the plugin is installed but the UI did not change" can simply mean you are not on the web profile rather than a broken plugin.

For a plugin that adds to the Web GUI, look under Settings → Plugin Market, which is DSH Plugin Hub.

Notes on the client module mechanism

Read the client module system as "a discoverer and composer of front-end modules" and it will not blur with plugin capability itself.

1. The Node half only organises: actual rendering is done by the browser half, so a UI problem has two stages to check.
2. It depends on the dsh.client declaration: without it a package is not in the front-end loading graph, even if it has front-end code.
3. Entries concentrate in __DSH_BOOT__: the page loads by it, so check membership there first when troubleshooting.
4. Scripts go through the /plugins combo path: loading relations are centrally managed, so adding plugins does not change page conventions.
5. It is optional: a UI-less run does not depend on it, and no visible UI change may just mean you are not on the web profile.
6. It affects the UI, not the conversation: even if front-end loading fails, the agent loop trunk runs as usual.
7. Its coordinates in the tree in DeepSeek Harness architecture; writing a plugin with UI in how to build a UI plugin.

Source: DeepSeek Harness docs - client modules subsystem, docs - architecture overview.