How to Modify DSH WebUI?

[elibroftw]

The demo says I can just tell DSH to show a whale, but when I asked it to modify the model selector to add a search feature, it said my changes would get wiped on the next npx update. How do we persist any modifications to the webUI? Should I just tell it to write diffs on top of modifying source?

[elibroftw]

Follow up prompt:

If we know that npx might wipe the changes, we should create diff files in a directory that won't get wiped, a memory file telling the model "if the user asks or reports the webUI has reset, apply diffs in dir X" and then apply the changes right now. Diff each file separately instead of using VCS. When applying diffs, don't use VCS as it might cause migration errors. Instead the diff file should explain what the intended outcome so that when the model is reapplying the change in the future, it can reconcile differences by itself.

[zhengyuzi]

Instead of modifying the source code, we should make it a plugin.

[elibroftw]

Would appreciate if they clarified whether plugins can do that, otherwise I'm just trying to go off the demo video which shows them adding a whale to the webUI by simply saying "Add a whale"

[zhengyuzi]

Yes, more prompts are needed to make the AI understand whether to create a plugin or modify the source code.

[weijiafu14]

@zhengyuzi is right, and for your specific example there is a concrete answer: the model selector is a slot, someone already occupies it, and you can too.

The seat exists. I enumerated the web shell's SlotMap declarations out of a real install tree (@deepseek-ai/dsh-client-ui-{layout,conversation,settings,input-trigger} and -sidebar, 0.1.1-rc.2) — 43 seats. One of them is conversation.input.model, session-scoped.

Someone is already sitting in it. reasoning-slider on npm ("Codex-style reasoning-effort slider embedded in the DSH model selector") is a client-only plugin whose lib/client.js registers into exactly conversation.input.model. So this is not theoretical — an out-of-tree package genuinely renders in the model picker today, and it survives npx updates because it is a separately installed package, not an edit to DSH's files.

The one catch for your case specifically: conversation.input.model is kind single, not list. Registering into a single seat replaces the occupant rather than appending to it. So "add a search box to the existing selector" is not what you get — you get "render your own selector, which can have a search box." That is a real cost (you reimplement the picker), and it is worth knowing before you start rather than after.

The traps, since they are all silent when you get them wrong — every one of these cost me a debugging session, and reasoning-slider's published package independently confirms the shape:

1. The package must declare dsh.client in package.json and export ./package.json. The host's client-modules scan resolves the manifest by subpath; without that export it throws ERR_PACKAGE_PATH_NOT_EXPORTED, the throw is swallowed, and the result is cached as "this is not a client package". Symptom: nothing renders, nothing in the console.
2. The client bundle is cjs, platform: 'browser', wrapped as window.__ModuleLoader__.load({ id, factory: (require) => { ... } }), and the factory body must declare its own var module = { exports: {} }; var exports = module.exports; — otherwise exports is not defined. (Compare the head of reasoning-slider/lib/client.js: same wrapper, same intro.)
3. Note the two different inject fields: dsh.client.inject in package.json is a client package-name dependency edge, while the inject your client source exports is the runtime service list (slots, inputTriggers, …). Mixing them up produces a bogus package dependency graph.
4. If you build server and client halves in two commands, the server build's clean will delete the client bundle whenever only the first runs (prepare does this). One config array, one command.

If a feature you want has no seat, that is still not the end. conversation.chat.node is keyed by node kind, so there is no seat for "re-render one fenced code block" — yet @puji4810/dsh-mermaid ships and works by taking the root entry and post-processing settled DOM. It is not an official contract and it breaks when the host changes markup, but it exists. Rule of thumb I now follow: search npm before concluding something is impossible — dsh-theme, dsh-tool-autoexpand, @fang2hou/dsh-locale-ja and @sharewiner/dsh-model-management are all doing this already.

On your follow-up prompt about a diff directory plus a memory file: I would not. Diffs against a moving upstream reconcile badly and you find out at the worst moment. A plugin has a stable published contract, survives updates by construction, and you can share it.

Interest disclosure: I maintain a DSH plugin with its own browser half, which is where all of the above was learned. None of it is specific to my package — it is the host's public contract, and the reasoning-slider evidence is a third party's.

[elibroftw]

At least for your own agent, prompt it to keep posts concise. Reading so much non-useful text has an opportunity cost itself.

[denial123789]

The plugin direction is confirmed by the rc.2 source, with two boundaries worth making explicit before implementing the model-selector example.

First, conversation.input.model is a Session-scoped single slot. A new occupant does not decorate the shipped selector; it shadows it and must own the complete model affordance (loading, current selection, effort, errors, disabled state, accessibility, and addressed-subagent behavior). If the requirement is only search, contributing it to the shipped selector may be cheaper than maintaining a full replacement.

Second, a package that loads on the Host is not automatically a Web plugin. The rc.2 Client registry resolves <entry>/package.json, requires dsh.client.platform === "web", resolves exports["./client"], reads the built artifact, and adds a revisioned boot row. Because manifest resolution failures are negatively cached for the process lifetime, fixing ./package.json export or dsh.client requires a Host restart before the package can be rediscovered.

The final browser artifact is also a specific contract: a browser-targeted CJS bundle that calls window.__ModuleLoader__.load({ id, factory }), not raw TypeScript or an ordinary ESM chunk. Keep clean: false across the dual output build so a later Client step does not erase the Node half (or vice versa).

I assembled a complete manifest skeleton, slot decision table, install-to-boot proof chain, failure router, removal test, and pinned upgrade checklist here: https://sandbaseai.github.io/deepseek-harness-handbook/persistent-web-ui-client-plugin.html

Disclosure: I maintain this independent SandBase handbook; it is not an official DeepSeek AI project.