DSH Desktop Bundles the DeepSeek Harness Into an Electron Shell
DeepSeek Harness Desktop App: a local AI desktop workspace for DSH Sessions, projects, files, web research, plugins, and Office artifacts.
At a glance
- What is it?
- A community desktop distribution that runs the official DeepSeek Harness npm runtime and dsh-web-app unchanged, then pins a set of verified community bundles on top. The interesting question is not what it adds but how much of it you are actually taking on.
- Who is it for?
- Adopt DSH Desktop if you want the official DeepSeek Harness web UI with a reproducible plugin set and you accept that the Profile is the single source of truth for plugin state. Do not adopt it if you are on macOS Intel or Linux and unwilling to run from source, or if you need remote access with a self-hosted server, since the README states no supported self-hosted server exists yet and independent password review plus real cross-network testing remain unfinished.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Plugin State Drift Across a Harness Install
DeepSeek Harness is an npm runtime with its own web app, sessions, agents, tools, skills, MCP support and settings. Getting a working install means assembling that runtime, choosing plugins, and keeping the plugin set consistent between the UI, the CLI and whatever the app does on restart. DSH Desktop targets exactly that gap. It is described in the README as a community-maintained desktop distribution that runs the official DeepSeek Harness npm runtime and the official dsh-web-app directly, with a set of community bundles that are pinned and verified. The audience is someone who wants to open an application and start from one Profile rather than build an environment and then maintain a second plugin state alongside it. The README states the client install directory holds only the application, while Profile, plugins, sessions and other DSH data live in a separate data directory, so moving the client does not migrate or delete that data.
Electron as a Thin Host, DSH as the Actual System
The main window is the official DSH Web, not a fork. Sessions, agents, tools, skills, MCP, settings and history are managed by DSH itself, and the README is explicit that there is no second chat page. Electron handles windows, native file selection, updates, startup and recovery. Anything the project adds is split into bundles. A portable plugin can therefore be installed into both a compatible official Web instance and DSH Desktop, while desktop-only capabilities must go through a narrow host contract the project calls desktop-adapter. That contract is bound per session and exposes a limited set of methods for files, windows and a Browser Workspace. The plugin market is implemented as a slot inside the official settings page rather than a replacement settings page or a separate plugin database, which is the mechanism that keeps the UI, the CLI and app restarts reading the same Profile.
Two Bundles Ship by Default, and Both Can Be Removed
A new Profile includes ds-harness-remote at a pinned version, supplied alongside DSH 0.1.5-rc.1. It enables continuing the same Workspace and Session from an Android app, a Remote Web client, or another Desktop. The README states the host only makes outbound connections and does not open a public listening port, and that the remote path tries LAN, P2P, TURN and Relay in order, with all paths carrying Noise IK encrypted traffic. Authorized devices are controlled through a fixed Harness API allowlist; direct shell, PTY and generic file RPC are not exposed. The second default is @vibeinging/dsh-session-teams, which lets session windows message each other as real DSH messages and lets one window act as a lead with role-based member windows. Both are removable through the official CLI, for example dsh plugin --profile web remove ds-harness-remote. The README notes that an upgraded existing Profile gets the remote bundle added once, and that a later update will not restore it if you disable or uninstall it.
Installing Plugins Through the Market or the CLI
The documented path for most users is Settings, then Plugin Market, which shows source, version, compatibility and permissions. The README adds a warning worth repeating: market visibility does not mean the project has reviewed or default-bundled a plugin, so read the upstream documentation before installing. The CLI operates on the same Profile: dsh plugin --profile web add -w <package>@<exact-version> --save-exact --ignore-scripts, and dsh plugin --profile web remove <package>. Plugins that satisfy the official DSH bundle and dshClient contract do not need a DSH Desktop rewrite. Plugins that need windows, native file dialogs or the Browser Workspace must use the desktop host contract explicitly, and the README says they should report a missing capability rather than fail silently when run in another host. Model credentials are handled by DSH settings and the local environment; the README states the project does not write API keys into the README, screenshots or plugin manifests.
Where the Distribution Stops Being Convenient
Platform coverage is uneven. macOS Apple Silicon gets a .dmg that the README says is Developer ID signed and notarized by Apple. Windows x64 gets an .exe with a choice of install scope and client directory, with the actual artifacts determined by the current Release page. macOS Intel and Linux have no official installer and must be run from source. That is a real boundary, not a footnote, because the desktop host and the update flow are part of what the distribution provides. The remote bundle carries its own caveats in the same document: the default connection uses third-party account, device directory, signaling and relay services at dsh.r2049.cn, and the README states that no supported self-hosted server is provided, that independent password security review is incomplete, and that real two-machine cross-network and long-term stability testing have not been done. Device identity and credentials are stored in DSH_HOME. If you do not need remote access, the documented answer is to remove the bundle rather than leave it idle.
What It Is Not Replacing
The obvious comparison is a plain DeepSeek Harness install with plugins added by hand. The difference is not features, it is who owns the plugin set. A manual install leaves you to track versions, compatibility and permissions yourself, and to reconcile whatever the UI and the CLI each believe is installed. DSH Desktop pins versions, checks integrity, permissions, dependencies and licenses for the bundles it ships, and keeps offline install artifacts so a new Profile can be initialized offline from fixed artifacts. The README also states that normal startup does not rewrite an existing Profile and does not silently reinstall a plugin the user removed. The trade-off runs the other way too: a hand-built install can track upstream DSH releases immediately, while this distribution ships against a specific line (DSH 0.1.5-rc.1 is named in the README badges) and its own release cadence, with v0.2.0, v0.2.1 and v0.2.2 arriving roughly a week apart in the release list.
Updates, Recovery and the Licence Position
Updates are opt-in rather than automatic. The README describes a button in the upper right that indicates an update, shows the changelog on hover, and only downloads, pre-checks the Profile and installs after a click. The pre-check is read-only, and the stated behavior is that it does not restore bundles the user disabled or uninstalled. If the Profile or the client is broken, the app enters a recovery page while keeping the original Profile. Anyone evaluating the upgrade cost should read that as a deliberate refusal to auto-migrate. On licensing, the repository is MIT, which covers this project's own code. It does not automatically cover the bundled third-party packages, the upstream DeepSeek Harness runtime, or the remote service; the README states the desktop package applies a SHA-256 verified compatibility projection to the fixed remote tarball without modifying the official DSH or upstream repository sources. Check each upstream package's own license before redistributing a build, and treat the remote service terms as separate from the MIT grant. This is a description of what the documents say, not legal advice.
Editorial conclusion
Adopt DSH Desktop if you want the official DeepSeek Harness web UI with a reproducible plugin set and you accept that the Profile is the single source of truth for plugin state. Do not adopt it if you are on macOS Intel or Linux and unwilling to run from source, or if you need remote access with a self-hosted server, since the README states no supported self-hosted server exists yet and independent password review plus real cross-network testing remain unfinished. Before committing, verify three things: that your platform has a signed installer on the Releases page, that you are willing to run dsh plugin --profile web remove ds-harness-remote if you do not want the preinstalled remote bundle, and that the third-party account and relay service at dsh.r2049.cn is acceptable for your data.
Community notes