DSH Desktop: a native shell around DeepSeek Harness

The gap DSH Desktop fills between Harness and a usable desktop app

DeepSeek Harness already ships the agent runtime and a Web UI. What it does not ship, according to the README, is a host: you start it yourself, you open a browser tab, and the surrounding state (profiles, plugins, workspaces, model settings, sessions) is not managed as a desktop product. DSH Desktop is that host. It starts Harness automatically, keeps the state outside the application directory so it survives upgrades, and opens the Harness interface once the local runtime is ready. The audience is narrow and specific: people who want the Harness agent loop on their own machine, with a directory picker and a menu bar, and who do not want to script the startup themselves. It is not a hosted service and it is not a new agent. Everything the README lists as an addition is host capability, which is the honest framing of what this project is.

How the Electron host and the loopback runtime fit together

The architecture described in the README is two processes with a deliberate boundary. The Harness Web UI is served only on a random loopback port, on 127.0.0.1, and the renderer runs without Node.js privileges, with context isolation and sandboxing enabled. Webviews, untrusted in-app navigation and unexpected permission requests are blocked, and external links are pushed to the system browser. That is a standard Electron hardening posture, and it matters here because the app loads a local web UI that can be extended by third-party plugins. Phone access does not punch a hole in the loopback listener. It uses a separate paired bridge, which can stay on the local network or, if you choose remote access, run through a temporary Cloudflare Quick Tunnel. The desktop asks you to approve the connection before the phone can reach sessions, and disconnecting the phone from the desktop invalidates the mobile session. The README also notes a fallback: if Cloudflare fails to start, the app tries Pinggy, and there is a Can't open? Try another link control for pairing links that do not resolve on the phone. That fallback chain is the kind of detail that only shows up after real-world testing, and its presence is a signal about where the authors expect breakage.

Installing it, and what the .dshpreset format buys you

Installers come from the official website for stable builds and from GitHub Releases for versions marked Pre-release. Installed builds check for updates shortly after startup and every six hours, ask before downloading, and only install after you choose Restart and install. You can skip one version without hiding future releases. The README states macOS releases are code-signed and notarized by Apple and Windows x64 installers are code-signed, with the caveat that Windows security warnings may decrease gradually as the publisher builds download reputation. The other installable unit is the preset. Agent presets import and export as .dshpreset packages, documented in docs/preset-packages.md, and the README is explicit that installation runs conflict checks and shows a trust warning first. That warning is the right call: a preset is a bundle of agent configuration, and importing one from a stranger is closer to installing a plugin than to loading a theme. If you plan to share presets across a team, the conflict check is the part to exercise before you rely on it, because it is the only thing standing between two presets that both claim the same names.

Safe Mode and the plugin failure path

The most interesting design decision in this project is the admission that third-party plugins can break it. DSH Desktop detects startup and frontend plugin failures, writes diagnostics to harness.log, and opens a guided recovery surface that tries to identify the implicated plugin from runtime and frontend evidence. Restart as Safe Mode, from the Harness menu, launches an isolated profile containing only official core bundles. The agent, sessions, model settings and workspaces stay available while third-party plugins from the normal profile stay blocked, and you can remove plugins or return to a normal launch from the Safe Mode banner. Recovery screens check for compatible plugin updates and Safe Mode offers batch upgrades. If the normal interface cannot be reached at all, the documented escape hatch is a launch flag. On macOS the README gives this example:

open -a "DSH Desktop" --args --safe-mode

Two things follow from this. First, the plugin surface is the real risk area, not the agent runtime. Second, the project treats plugin breakage as an expected state rather than an incident, which is a more honest posture than most desktop wrappers adopt. The cost is that Safe Mode is a reduced environment: if your workflow depends on a plugin, Safe Mode is a diagnostic tool, not a fallback you can work in.

PPT generation is a bundled runtime, not a general document tool

PPT mode is enabled with a button, after which you choose a template and describe the deck. The built-in catalog is described as 16 templates and 192 layouts, with editable PPTX output. Previews use English while decks can be English or Chinese with corresponding font settings, and the README warns that preview language does not determine output language. PPT is preinstalled, and its automatic instructions apply only to sessions where the PPT button is enabled, which means the extra instructions are scoped rather than global. The runtime guide lives at packages/ppt-runtime/README.md and covers templates, validation and source acknowledgments. Treat this as a bounded feature with a fixed template set. The layout count is large, but the catalog is finite, and the README does not describe a mechanism for supplying your own templates. If your decks need a house style that is not in those 16, this feature will not get you there without work the README does not document.

The early-preview constraint and where it becomes the wrong tool

The README carries its own warning: DSH Desktop is an early preview built on the rapidly evolving @deepseek-ai/dsh@0.1.2-rc.1. That single sentence is the main limitation. The host is pinned to a release candidate of the runtime it wraps, so Harness changes can move underneath it. The release history supports the reading that the project is still settling: v0.8.0 arrived on 2026-09-10, three days after 0.8.0-rc.3 and two days after 0.8.0-rc.4, and the stable channel is described as the one recommended for everyday use while preview releases closely track the latest official Harness versions and may be incompatible with community plugins. So the failure mode is concrete: if you are the kind of user who wants the newest Harness and a healthy set of community plugins at the same time, this project explicitly does not promise that combination. The second limitation is structural rather than temporal. The renderer has no Node.js privileges and webviews are blocked, which is good for safety but means plugin authors cannot reach for host APIs the way they might in a less restricted shell. If your plugin needs that access, DSH Desktop is the wrong host, and no configuration will change it.

What you give up compared with running Harness directly

The alternative is running DeepSeek Harness yourself. That path gives you the Web UI on your own terms, no Electron layer, no installer, no update prompt every six hours, and no pinned runtime version: you take whatever Harness release you choose, the moment you choose it, and you can patch or vendor it. The difference in approach is where the state and the lifecycle live. With DSH Desktop, the app owns startup, shutdown, profile location, plugin isolation and recovery, and you get Safe Mode and harness.log as part of the deal. With a self-managed Harness, you own all of that, and you get no guided recovery when a plugin breaks startup, because there is no host to detect it. Neither is strictly better. The desktop app trades version freedom for operational convenience and a diagnostic surface; the direct route trades that surface for control. The README's own framing of the phone bridge, the Cloudflare-then-Pinggy fallback and the Safe Mode banner all describe work you would otherwise do by hand.

Licence, upgrade cost and what to check first

The project is MIT-licensed, and the README links to a LICENSE file. MIT is permissive, so redistribution and modification are allowed subject to its terms; that is a statement about the repository licence and not legal advice, and it says nothing about the licence of DeepSeek Harness or of the model providers you configure, which you should check separately because DSH Desktop supports official DeepSeek models alongside mainstream third-party providers. On maintenance cost, the material points to three recurring items. The runtime pin: because the app is built on a release candidate of @deepseek-ai/dsh, every Harness bump is a potential compatibility event, and the preview channel is where that risk lands. Plugin drift: the README states preview releases may be incompatible with community plugins, so plugin compatibility is a moving target you will re-check after upgrades. And platform signing: macOS builds are notarized and Windows builds are code-signed, but the README itself notes Windows warnings may persist until publisher reputation accumulates, which is a support burden rather than a technical one. Before you adopt it, verify that your plugins run under a normal profile rather than requiring Safe Mode, that the --safe-mode launch path works on your machine, and that your OS build is signed for your platform. If those three hold, the host earns its place; if any fails, run Harness directly and keep the version control.

Editorial conclusion

Adopt DSH Desktop if you already want DeepSeek Harness running locally and would rather not manage a CLI and a browser tab, and if you can tolerate a preview built on @deepseek-ai/dsh@0.1.2-rc.1. Do not adopt it if you depend on community plugins that must track the newest Harness release, or if you cannot accept a third-party plugin affecting startup. Before committing, verify three things: that your platform build is signed for your OS, that your plugins run under a normal profile rather than Safe Mode, and that the `--safe-mode` launch path works on your machine.

Official sources

1. dataelement/dsh-desktop on GitHub
2. License: MIT
3. Project website
4. README
5. Releases