DSH Desktop: a native shell for DeepSeek Harness, with the desktop itself written as a plugin

What DSH Desktop actually packages

DeepSeek Harness ships a local web UI, a host service and a plugin system. Running it normally means managing a Node.js toolchain and starting the host yourself. DSH Desktop wraps that stack in a native application: the README says the app starts and manages the local Harness service, integrates a system tray and a desktop window, and requires no Node.js installation or command execution.

The audience is correspondingly split. End users get an installer and a Setup Wizard. Plugin authors get a runtime where the desktop shell is itself a DSH plugin, so window management, tray behaviour, terminal and update logic are composed through the same plugin contract as third-party extensions. That second group is where the project's argument lives, and the repository reflects it: docs/plugin-development.md, dsh-plugin-desktop/docs/plugin-services.zh.md and a draft contract under dsh-community-fabric/.

One disclaimer matters before anything else. The README states this is an independent community project with no affiliation, partnership, authorization or endorsement from DeepSeek, and that no DeepSeek employees or upstream DeepSeek Harness team members currently participate. Contributor lists showing upstream names are attributed to fork inheritance and synchronized commit history.

Pinned upstream, plugin-composed shell: how the runtime is assembled

The repository is a Yarn 4 workspace with four members: dsh-plugin-desktop, dsh-plugin-desktop-beta, dsh-community-fabric and dsh-community-market. The root package.json is private and declares engines of node ^22.19.0 or >=24.0.0. Upstream Harness packages are not pulled from a registry at install time. They are resolved to tarballs under vendor/dsh-runtime/0.1.5-rc.2/ through the resolutions field, for example @deepseek-ai/dsh-invariants mapped to file:vendor/dsh-runtime/0.1.5-rc.2/deepseek-ai-dsh-invariants-0.1.5-rc.2.tgz. The repository also carries a patches/ directory and a deepseek-harness submodule entry, so the pinned runtime is materialized in-tree rather than fetched.

That is the mechanism behind the README's claim that the project does not modify upstream source and is not a hardcoded shell. A fixed upstream version runs as-is; the desktop layer attaches through the plugin mechanism the upstream exposes. The practical consequence is version coupling. If a plugin needs an API that landed after the pinned Harness version, it does not work here until the pin moves. The trade-off is deliberate: a fixed upstream is testable, but it means DSH Desktop's compatibility surface is a snapshot, not a range.

A second mechanism is profile-scoped first run. The README states that each uninitialized profile shows a native Setup Wizard before anything else, covering window mode and system material, the plugin market, notifications, whether to open the system browser automatically, and web access scope. Host and the main DSH window do not start until the wizard is completed or skipped, and completion is recorded per profile.

Installing DSH Desktop and running a first session

The README gives two install paths and no build-from-source instructions for end users. Windows x64 uses an NSIS installer; macOS Universal uses a DMG. Both are served from the project homepage, and the README states no additional environment is required.

On Windows, download the installer and run it:

# Windows x64: download from https://www.dshdesktop.cn/api/downloads/windows
# then run the NSIS installer and follow the prompts

On macOS, open the DMG and drag the app into Applications:

# macOS Universal: download from https://www.dshdesktop.cn/api/downloads/mac
# open the DMG, drag DSH Desktop into Applications

On first launch of a profile that has not been initialized, the Setup Wizard appears before the Host and the main window. The README lists what it configures: window mode and system material, the plugin market, notifications, whether to open in the system default browser, and web access scope. It can be skipped. If you skip it, the Host starts with defaults, and the web service listens on the loopback address only.

After the wizard, the main window is the Harness web UI running against the locally managed host. The README notes that the desktop settings panel displays the actual local URL under the browser option, and that enabling the browser option does not change the network exposure range; it only hands the ready URL to the system browser.

For plugin work, the README points at docs/user-guide.md for plugin commands and docs/plugin-development.md for authoring. It does not inline the command syntax, so treat those two files as the source of truth rather than guessing at flags.

LAN mode has no authentication, and the README says so

Local network access is an opt-in setting, separate from the browser option. The README carries an explicit warning: opening the service to the LAN provides no authentication, and anyone on the same network can open DSH and operate your machine. It advises enabling it only on a network you fully trust.

This is the sharpest limitation in the documentation, and it is stated rather than buried. It also clarifies a common misreading: "open in browser" and "LAN access" are different switches. The first changes which program displays the UI. The second changes who can reach it. Only the second one expands the attack surface.

A second boundary is platform. The README lists Windows x64 and macOS Universal. Linux is not offered. If your workflow is headless or container-based, this project is the wrong shape, because the value it adds is a tray, a window and an installer, none of which exist in a headless context.

A third is the pin itself. Because the upstream Harness version is fixed and vendored, upstream bug fixes and new plugin APIs arrive when the maintainers re-pin, not when upstream publishes. Anyone depending on a recently added Harness capability should check the vendored version before adopting.

How DSH Desktop differs from running DeepSeek Harness yourself

The direct alternative is the upstream DeepSeek Harness repository, which the README links. Running it yourself gives you the current upstream version, your choice of Node runtime, and no third-party packaging layer. You also get the setup work: installing Node, resolving dependencies, starting the host, and managing updates by hand.

DSH Desktop trades that control for a managed runtime. It pins a Harness version, vendors the tarballs, ships an installer, and adds a Setup Wizard, a tray, update checks and a plugin market. The difference is not features versus no features, it is who owns the version decision. Upstream users own it and absorb breakage. DSH Desktop users inherit a tested combination and wait for re-pins.

There is a second comparison inside the project itself. The README frames the plugin model as the differentiator: extensions for models, tools, interfaces and workflows, all following one contract, with the desktop shell obeying the same rule. Whether that holds depends on the contract in dsh-community-fabric/, which the repository labels a draft. A draft contract is a real signal about maturity, and it is the part most likely to change between releases.

On updates, the README documents the request shape: version checks send X-DSH-Desktop-Version, X-DSH-Desktop-Channel with stable or beta, and X-DSH-Desktop-Installation-Id carrying a locally generated persistent random UUID that the README says is not derived from hardware. Installer downloads carry the channel and X-DSH-Desktop-Target-Version, and the README states the download request and its redirects do not carry the installation ID or the current version. That level of detail is unusual and worth reading before you decide what the update channel tells the maintainers.

Maintenance, releases and what the MIT licence covers

The repository is not archived, and the last push was on 2026-09-16. Releases are frequent: v2.0.9 on 2026-09-10, v2.0.10-beta.1 and v2.0.10 on 2026-09-13. The channel split is visible in those tags, matching the stable and beta values the update headers carry.

Upgrade cost is mostly the pin. Every release re-vendors a specific Harness version, so upgrading DSH Desktop can change the plugin API surface underneath your extensions. If you maintain a plugin, test against the vendored version in the release you target rather than against upstream main. The repository layout makes this checkable: vendor/dsh-runtime/ and upstream.json record what is bundled.

The licence is MIT, at the repository root. MIT is permissive and imposes no copyleft obligation on your own plugin code. Two things sit outside that. First, the pinned upstream packages are redistributed under their own terms, and the vendored tarballs are the place to check them. Second, the project carries sponsor placements in the README and a separate privacy policy in PRIVACY.md, PRIVACY.zh.md and PRIVACY.i18n.yaml. None of this is legal advice; if you redistribute the bundled runtime commercially, read the vendored package licences yourself.

Editorial conclusion

Adopt DSH Desktop if you want the DeepSeek Harness agent loop on a desktop without installing Node.js or running commands, and if you accept that the bundled Harness version moves only when the project re-pins it. Skip it if you need Linux, if you rely on upstream fixes landing the day they ship, or if you plan to expose the web service beyond localhost, since the README states LAN mode adds no authentication. Before installing, check the release notes for the pinned Harness version and read docs/user-guide.md for the plugin commands, because the README itself only links to them.

Frequently asked questions

Official sources

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