What DSH Desktop is, mechanically
DSH Desktop is a packaged desktop application, not an add-on you install into an existing harness. It carries a pinned copy of upstream DeepSeek Harness and runs that version as-is — the README states the upstream sources are not modified. Around that runtime it wraps the harness’s local Web UI, its Host service and its plugin system in a native desktop application, and it applies the ecosystem’s own rule to itself: the desktop shell — window, tray, terminal, update and work-configuration surface — is loaded as a DSH plugin and composed into the same runtime through the harness’s own plugin mechanism.
The repository is a Yarn workspace whose manifest is named deepseek-harness-desktop, marked "private": true, and contains no version field and no dsh field. That is the mechanical consequence a reader should take away: this is a product workspace, not an npm-published DSH plugin package. The README is explicit that it is an independent community project with no affiliation, cooperation, authorization or endorsement from DeepSeek, and that no DeepSeek employees or upstream DeepSeek Harness team members participate in it; upstream names that appear on the GitHub Contributors page come from fork inheritance and synced commit history, and reflect commit provenance only.
What the desktop shell actually does
The README splits responsibility with upstream: upstream supplies the agent, model, tool, session, Web UI and plugin ecosystem, while DSH Desktop handles desktop application packaging, starting and stopping and recovering the local service, desktop window and system tray integration, macOS and Windows installer builds and releases, and a desktop-oriented interface experience. The named features are:
- Desktop — the application starts and manages the local Harness service itself and presents it in a native window with system tray integration. The README’s claim is that you do not need to install Node.js or run commands.
- Setup Wizard — on the first normal launch of a profile that has not yet been initialized, Desktop shows its own native Setup Wizard. It can set window mode and system material, the plugin market, notifications, whether to auto-open in the system default browser, and the Web access scope; it can also be skipped. Until it is completed or skipped, the Host and the main DSH window do not start. Completion or skip is recorded per profile, and an explicit recovery start still enters the recovery assistant first.
- Web service scope — the Web service listens on the loopback address only by default. Enabling “open in browser” hands the URL to the system default browser once the Web service is genuinely ready, and the README says this option does not change the network exposure. Desktop settings shows the real local URL, and LAN access is a separate optional switch that also displays the current LAN URL.
- Plugin market — DSH Community Market is documented as complete and built in, covering plugin discovery, detail views, installation and management. It is designed to connect openly to plugin data sources that follow a public schema, and existing APIs can join as partner data sources through reviewed adapters.
- Work configuration — viewing and switching work configurations is named as an available desktop capability for plugin authors.
What the README does not do is enumerate interface features beyond these. Anything you have read elsewhere about panels, launchers or multi-window session grids has no source in this document.
The plugin ecosystem is the architecture, not an add-on
Everything in the product follows one rule: upstream plugins, DSH Desktop plugins and other community plugins share the same conventions and compose through the same mechanism, and DSH Desktop is itself a DSH plugin. Because the pinned upstream version runs unmodified, the README’s formulation is that plugins compatible with that pinned version can be used — it makes no statement about plugins built against a different upstream version.
For plugin authors there is a real surface, not just a slogan: Desktop exposes services so that a plugin can integrate with desktop capabilities, with reading and switching work configuration and installing, updating and removing plugins in the current configuration given as examples. The README says which capabilities are deliberately withheld from third-party plugins is discussed in the why-desktop and plugin-development documents; it does not list them in the README, so the contents of that boundary are not stated here.
Install, platforms and requirements
Released installers cover exactly two targets, and the README says no additional environment is needed:
| Platform | Download | How it installs |
|---|---|---|
| Windows x64 | NSIS installer | run it and follow the prompts |
| macOS Universal | DMG | open it and drag DSH Desktop into Applications |
Two things follow from that table. Linux is not mentioned anywhere in the README, so it should be treated as unsupported rather than merely untested. And macOS ships as a single Universal build, so there is no documented Intel-versus-Apple-Silicon split to choose between.
Building from source is a different requirement set. The outer repository uses Yarn, and a pinned deepseek-harness/ submodule keeps its own pnpm workspace; the documented sequence is git submodule update --init --recursive, then corepack yarn install --immutable, then corepack yarn dev, with corepack yarn check for headless checks. The workspace manifest declares packageManager: yarn@4.18.0 and engines.node of ^22.19.0 || >=24.0.0, and its scripts drive macOS and Windows packaging. Stable and Beta desktop packages live in dsh-plugin-desktop/ and dsh-plugin-desktop-beta/.
Known limits, and what the README does not say
The README has no limitations section, and some of what a reader will want to know simply is not in it. Stated plainly:
- LAN exposure has no authentication. This one is documented as a danger, not a footnote: opening the Web service to the local network provides no authentication, and everyone on the same network can open DSH and operate your computer directly. The README says to enable it only on a network you fully trust. The default is loopback-only.
- Mobile remote control is not shipped. iOS and Android remote control is listed with a “coming soon” badge: connecting to Desktop from a phone, starting tasks there and following agent progress. It is an announcement, not an available feature.
- Linux is not stated. Only Windows x64 and macOS Universal appear.
- Code signing and notarization are not stated. Nothing in the README says whether the Windows installer or the macOS DMG is signed or notarized.
- Telemetry is not stated. The README documents one outbound request (below) but never says there is no telemetry, so the absence of a telemetry section is silence, not a guarantee.
- Credential storage and data handling are not stated in the README. It links to a separately maintained privacy policy for data processing and privacy choices rather than summarizing it inline, so where credentials or session data live cannot be sourced from these documents.
- Third-party licence compliance for bundled components is not stated. The project is MIT licensed; what the packaged application redistributes is not addressed.
- Sandboxing and offline operation are not claimed. Neither appears in the README, and an application that checks for updates and downloads installers should not be assumed to work offline.
- There is no published version field. The workspace manifest has no
version, so the README’s release badge is the numbering you see, not a field in this file.
The one documented network call
The README discloses exactly one network interaction: the fixed-version auto-update check. That request carries the currently installed version in an X-DSH-Desktop-Version header, stable or beta in X-DSH-Desktop-Channel, and a locally generated, persistently stored random UUID in X-DSH-Desktop-Installation-Id — which the README explicitly says is not an identifier derived from hardware information. The installer download carries the channel and X-DSH-Desktop-Target-Version, while the download request and its redirects carry neither the installation identifier nor the current version.
That is the whole of what is documented. No other endpoint, payload or retention behaviour is described, and the README does not describe what the local harness service itself does with your model traffic — that belongs to the upstream project.
When to use it — and when not to
Use it if you want the harness in a normal desktop window and would rather not install Node.js or run a command to get there; if you want the desktop shell to be replaceable by plugins the way everything else is; or if work-configuration switching and a built-in plugin market are the parts you care about. The project’s own framing is the phone-app analogy: plugins developed to one set of rules, installable together without interfering.
Skip it if you work on Linux, since only Windows x64 and macOS Universal are stated. Skip it if what you actually want is the command line — the README itself redirects anyone who wants to run DeepSeek Harness from a terminal, or to work on core features, to the upstream repository. If phone control is the requirement, the feature you want is announced rather than shipped; the README’s own ecosystem link list names adjacent projects for that purpose, Agents-Anywhere (“remote control of a coding agent on your computer from a phone”) and deepseek-harness-remote (P2P- and APIProxy-based remote control and multi-device collaboration). The README lists them as friendly projects; it does not compare them with DSH Desktop, so treating them as substitutes is a reader’s inference, not a documented equivalence. The same caution applies to the lighter-weight interface projects in that list, such as DSH-better-sidebar, dsh-web-ui, dsh-TUI and dsh-tianshu-tui: they are catalogued there, not positioned as alternatives. One further trace worth knowing: the workspace’s release scripts include an aa:prepare-release step that runs a prepare-Agents-Anywhere-release script, but the README does not explain what that step bundles.
Finally, a security decision rather than a feature decision: if the network you are on is not fully trusted, leave LAN access off, because enabling it exposes an unauthenticated way to operate your machine.
FAQ
Is DSH Desktop an official DeepSeek product?
No, and the README says so explicitly. It describes DSH Desktop as an independent community project built on DeepSeek Harness and Cordis plugin ideas, states there is no affiliation, cooperation, authorization or endorsement from DeepSeek, and states that no DeepSeek employees or upstream DeepSeek Harness team members take part in its development, maintenance or governance. Upstream contributors visible on the GitHub Contributors page come from fork inheritance and synced upstream commit history; the README says that attribution reflects commit provenance only, and does not mean those people are involved in this repository. “DeepSeek Harness” is a trademark of DeepSeek, used in the README only to describe compatibility and technical origin.
Do I need Node.js to run it?
Not for the released installers. The README says the packages need no extra environment, the application starts and manages the local Harness service for you, and you do not need to install Node.js or run commands. Running from source is the opposite case: that path needs Yarn and the pinned deepseek-harness/ submodule, and it inherits the workspace manifest’s engines.node range of ^22.19.0 || >=24.0.0.
Can I drive it from my phone?
Not from anything that is shipped. The README presents iOS and Android remote control behind a “coming soon” badge — connecting to Desktop from a phone, starting tasks and following agent progress. Treat that as announced, not available. For phone control today, the README’s friend-link list points at other projects, and the README does not say how they relate to this one.
Is it safe to open to my local network?
The README answers this directly and negatively: LAN access provides no authentication, and everyone on the same network can open DSH and operate your computer. It advises enabling it only on a network you completely trust. The default is loopback-only, and switching on “open in browser” does not change that.
Does it send anything to a server?
One interaction is documented: the fixed-version update check carrying the installed version, the channel, and a locally generated persisted random UUID that the README says is not hardware-derived. The README does not state that there is no telemetry, does not describe credential storage, and defers data handling to a separate privacy policy it links but does not summarize — so those questions are unanswered by the documents this listing is based on.