English | 中文
A collection of plugins for the DeepSeek Harness — modes for its web GUI, panels around the conversation, two ways to hand it something it cannot read on its own (documents, pictures), a way onto other machines, a keyboard map, two top-row readouts (spend, project status), and a hub that installs and configures the rest from inside Settings. Three applications to run them in, and a catalog so the hub can find them.
Nothing here modifies the harness. Every feature ships as an out-of-tree bundle that a profile composes over dsh-base, through seams the harness already publishes: a slot, a service, a settings namespace, a route. That constraint is the whole design — the harness stays a tracked fork that can follow upstream, and a plugin written next year installs into a profile assembled today without either knowing about the other.
Thirteen plugins, three applications, and one catalog.
| Package | What it adds |
|---|---|
| omdsh-basemode | The session-mode system: the registry every mode plugin registers a segment into, the switch that renders them, and the dots that colour the sidebar by mode. It invents no mode, and contributes one: Work, the harness's own column, so a switch always has somewhere to switch back to. |
| omdsh-chatmode | Chat and Work. Chat starts a conversation without picking a project directory and keeps those conversations together in a managed workspace. |
| omdsh-codemode | Code. A harness terminal in the conversation's workspace, running as the column rather than beside it. |
| Package | What it adds |
|---|---|
| omdsh-sidepanel | A file tree down the right edge and a terminal along the bottom, in Work mode. |
| omdsh-sidechat | A side conversation summoned anywhere, carrying whatever you were looking at as its anchor. Never touches the conversation you are running. |
| omdsh-usage | Session spend, project spend, and account balance in the conversation's top row. |
| omdsh-status | The current project's name with its git branch and change counts, at the right end of the conversation's top row. |
| omdsh-editor | Open the conversation's directory in the editor, terminal, or file manager you actually use. |
A DeepSeek route carries text and nothing else. These two hand it the rest of what a person has on their desk, by turning it into text before it gets there.
| Package | What it adds |
|---|---|
| omdsh-document | Attach a Word file, a deck, a spreadsheet, a PDF or any text file — from Document under the Attachments heading these two put in the composer's plus menu, by dropping it on the window, or by pasting it into the message box — and the host puts its text in front of the message, without a mark in the message box. |
| omdsh-vision | Sight, from a vision model you configure. Add a picture or a video from Multimedia in the same menu; drop or paste a video the same way. Pictures pasted or dropped stay in the harness's own composer rail — and the agent gets see_image, ask_image and watch_video for the ones already on disk. |
| Package | What it adds |
|---|---|
| omdsh-remctrl | A second front door on its own port, behind device pairing and a tiered method allowlist, so a phone on your tailnet can watch a session and approve what it asks for. Status: M0 — the door and the lock. |
| Package | What it adds |
|---|---|
| omdsh-plughub | The plugin hub: a Settings tab that installs, disables and configures these plugins from the settings schema each already registers. The hub and the mode system stay on. |
| omdsh-shortcuts | One chord per command, on the desktop menu and in the page alike — one document, two surfaces. The reference implementation for the conventions. |
| Repository | What it is |
|---|---|
| omdsh-desktop | An Electron shell that supervises a harness runtime and adds the native surface around it — windows, menus, restart policy, boot screen. |
| omdsh-tui | An interactive terminal for the harness, shipped as an installable profile bundle. omdsh-codemode runs this in its column. |
| omdsh-webapp | A packager that writes the web UI into a double-clickable macOS application: it starts a profile from the Dock, raises the tab already showing it, and stops the server when it quits. |
Each carries a pnpm workspace of its own, which is why none of them is a member of this one. None composes a layer into a profile either, so none appears in the catalog.
⬇️ Download the desktop application — nothing else needed on the machine, the runtime and the plugin hub are inside it: macOS (Apple silicon) · Windows (x64) · all releases
| Directory | What it is |
|---|---|
| registry/ | A generated manifest of every plugin here, so omdsh-plughub can offer them without enumerating a GitHub account one request at a time. |
┌──────────────── omdsh-plughub ────────────────┐
│ installs · disables · configures everything │
└───────────────────────────────────────────────┘
omdsh-basemode ──── the mode registry, the switch, the dots, and Work
├── omdsh-chatmode ── Chat · Work
└── omdsh-codemode ── Code
omdsh-shortcuts ── the `shortcut` service; every chord in the app
omdsh-remdev ───── the `remdev` service; sidepanel and codemode ask it about a cwd
omdsh-sidepanel · omdsh-sidechat · omdsh-usage · omdsh-editor
omdsh-status
surfaces beside the column, each answering for itself when a
companion is not installed
Three services here are published by plugins rather than by the harness: sessionModes (omdsh-basemode), shortcut (omdsh-shortcuts), and remdev (omdsh-remdev). Whether one exists is a property of the profile a person assembled, so no plugin names another plugin's service in a top-level inject — it reaches for it inside apply, on a restricted fiber, and stays inert when it is absent. One missing companion must never take the page down. That is rule 9 of the conventions, and it is why any subset of this collection composes.
You need a global dsh, Node ^22.19.0 || >=24.0.0, and pnpm 11.7.0.
Install omdsh-plughub once, then install everything else from inside Settings:
dsh plugin --profile web add @omdsh-plugins/omdsh-plughub
dsh --profile webOpen Settings → Plugins → Plugin hub, and the collection is listed with an Install button on each card. The hub reads the registry manifest, so a plugin published after you installed the hub still appears.
Every install, update, and removal takes effect on the next start — the hub says so on the card, and the harness's loader does not hot-swap a bundle.
The hub ships a command, and it installs anything in the catalog by name:
npx @omdsh-plugins/omdsh-plughub list # what is on offer
npx @omdsh-plugins/omdsh-plughub add omdsh-basemode omdsh-chatmode omdsh-codemode
npx @omdsh-plugins/omdsh-plughub remove omdsh-codemodeThat is the Settings tab's installer with argv where the button was — the same catalog, the same specifier, the same dsh plugin underneath — so a plugin added this way is the same dependency and the same bundle row. It writes into the web profile unless --profile says otherwise, and that profile has to exist first: dsh --profile web writes one.
Every plugin but the hub is why it exists. Two packages install from npm: omdsh-plughub, the bootstrap in the section above, and omdsh-basemode, the mode system chatmode and codemode register into. The rest install from their GitHub repositories, so dsh plugin --profile web add @omdsh-plugins/omdsh-chatmode answers ERR_PNPM_FETCH_404 and changes nothing — the profile is left exactly as it was. The git specifier that would work needs a pnpm build-allowlist key carrying the commit pnpm resolved, which can be copied out of a failure and never written down in advance; the command writes it for you.
Order is a readability preference, not a requirement: a plugin composed before the service it wants waits on a restricted fiber rather than failing.
A version of the hub or of omdsh-basemode published in the last 24 hours does not install by name — through dsh plugin. That is pnpm's caution and not npm's, so the npx line above is unaffected. pnpm holds a fresh release at arm's length — minimumReleaseAge defaults to a day — so an add run the morning after a release quietly records the version before it, and the hub then offers an update to the one you thought you asked for. Name the version, or waive the delay for that one command:
dsh plugin --profile web add @omdsh-plugins/omdsh-plughub@<version>
dsh plugin --profile web add @omdsh-plugins/omdsh-plughub --config.minimumReleaseAge=0The minimumReleaseAge: 0 in this workspace's pnpm-workspace.yaml does not reach that install: the profile directory is its own pnpm root and inherits nothing from here.
Remove the hub the same way:
dsh plugin --profile web remove @omdsh-plugins/omdsh-plughubThe hub and the mode system are published; everything else, and a plugin you are changing, is never the published one, so a profile assembled here installs from the working tree. Build first — dsh plugin add records a link: dependency, so the installed files are the checkout, and a checkout with no lib/ cannot be loaded:
pnpm install
pnpm run build
dsh plugin --profile web add "$PWD/omdsh-basemode" "$PWD/omdsh-chatmode" "$PWD/omdsh-codemode"omdsh-tui is not a workspace member and installs into a profile of its own, which is where omdsh-codemode looks for it:
cd omdsh-tui && pnpm install && pnpm run install:profileCode mode needs that profile. Without it, pressing Code renders dsh: profile "omdsh-tui" does not exist inside the terminal column — the rest of the app is unaffected.
A profile composes exactly one surface bundle over dsh-base. @deepseek-ai/dsh-web-app and @omdsh-plugins/omdsh-tui-app are both surfaces and collide on seven loader ids, so the terminal lives in its own profile (omdsh-tui) and never alongside web. The feature plugins in this collection are not surfaces and stack freely.
A plugin with anything to configure registers one settings namespace with a schemastery schema, and omdsh-plughub renders a form from that schema — labels, descriptions, validation, secret redaction, and the base/user layering all come from the harness. No plugin teaches the hub anything about itself, which is what lets a plugin installed today get correct labels in both languages without the hub being edited.
Six plugins own a namespace: omdsh-plughub, omdsh-shortcuts, omdsh-remctrl, omdsh-usage, omdsh-document, omdsh-vision. The rest are configured, where they are configurable at all, in the profile's own cordis.patch.yml — each README says which it is.
A field holding a credential is declared .role('secret'), stripped from every response, and rendered as a write-only control.
The full README — the half this page leaves out: the commands, the tooling's known rough edges, and what a plugin here agrees to. Everything on one page, with the catalog and the conventions, is on the site.
