DSH Desktop: an Electron shell around the official DeepSeek Harness runtime

What problem DSH Desktop solves, and for whom

The upstream DeepSeek Harness ships as an npm runtime plus a web app. Getting a usable desktop environment out of that means picking a runtime version, choosing bundles, resolving their dependencies, and keeping the plugin state consistent across the UI and the CLI. DSH Desktop is a community-maintained distribution that does that assembly once and freezes it.

The README is explicit that the app runs the official runtime and the official dsh-web-app directly rather than a private chat fork. The main window is the official DSH Web, and sessions, agents, tools, skills, MCP servers, settings and history stay under DSH's own management. There is no second chat page.

So the audience is narrow and specific: people who already want DSH sessions and are willing to run a desktop host around them. If you have no interest in the DSH session model, this project gives you nothing that a plain Electron file browser would not.

The thin-host architecture and where plugins actually live

The repository layout reflects the split. The Electron main process lives under electron/, with packages/, server/, scripts/ and eval/ alongside it; package.json sets "main" to electron/main.js and marks the project private at version 0.2.5, while the latest release is v0.2.2 from 2026-09-10. That version mismatch is normal for a repo that tags releases separately, but it does mean the package.json version is not the thing to quote when reporting a bug.

The README describes Electron as a very thin desktop host. Agent, session and plugin systems remain DSH's; project-specific features are split into bundles. Plugins that follow the official DSH Bundle and dshClient contract do not need a DSH Desktop rewrite. Only plugins that need windows, native file dialogs or a Browser Workspace must use the narrow desktop-adapter host contract, and the README says such a plugin should report the missing capability plainly when run in another host.

The single source of truth is the DSH Profile. The plugin market in the official settings page, the CLI, and the app restart all read and write the same profile. That is the design decision worth noting: there is no separate plugin database to drift out of sync, which is the usual failure of desktop wrappers that keep their own registry.

Installing DSH Desktop and running a first session

The download table in the README lists macOS Apple Silicon as a .dmg that you drag into Applications, described as Developer ID signed and notarized. Windows x64 is a .exe where the installer asks for an install scope and a client directory, and the README says the artifacts on the current release page are authoritative. macOS Intel and Linux have no official installer; the README says those users can run from source.

After launch, the documented first-run flow is short. Pick a working directory or create a session directly, then open files, Git or the terminal from the sidebar, and attach files and folders from the input box.

dsh plugin --profile web remove ds-harness-remote

That command removes the bundled remote plugin from the web profile. It is the documented way to drop the remote feature without touching anything else.

The README notes that the client install directory holds only the application. Profiles, plugins, sessions and other DSH data live in a separate data directory, so moving the client does not migrate or delete them. Model credentials are managed by DSH settings and the local environment; the project states it does not write API keys into the README, screenshots or plugin manifests.

Installing plugins through the market or the CLI

The plugin market sits inside the official settings page using an official settings slot. It does not replace the settings page and does not create its own plugin database. It shows source, version, compatibility and permissions before install.

The README is careful about what market visibility means. It states that you should still read the upstream documentation, because being listed is not the same as being reviewed or bundled by default. That is the honest framing, and it is the opposite of the usual marketplace copy.

The CLI route operates on the same profile, with an exact version pin and scripts disabled:

dsh plugin --profile web add -w <package>@<exact-version> --save-exact --ignore-scripts
dsh plugin --profile web remove <package>

The --save-exact and --ignore-scripts flags are the notable part. Pinning an exact version and refusing install scripts removes two common ways a plugin install turns into an unreviewed code execution path. The cost is that you will not pick up patch fixes automatically, and any plugin that genuinely needs a postinstall step will not work under this command.

What ships by default, and the remote dependency

A new profile is initialized offline from a fixed artifact bundled with the app. Normal startup does not rewrite an existing profile, and the README states the app will not quietly reinstall plugins the user removed.

Two bundles ship by default. @vibeinging/[email protected] lets DSH session windows message each other: you tell the current window to hand something to a named window, and the message arrives as a real DSH message that is visible, persistent and traceable back to its source. A window can also act as a team lead, assigning tasks and dependencies, with members reporting back as real messages. All team and window state goes through the official Session API in the current profile, with no external network connection. It can be removed with:

dsh plugin --profile web remove @vibeinging/dsh-session-teams

The second default is [email protected], pinned to the DSH 0.1.5-rc.1 line. It lets Android, Remote Web or another Desktop open the same workspace and session. The README states the host only makes outbound connections and does not open a public listening port, and that remote tries LAN, P2P, TURN and Relay in turn, with Noise IK encryption on every path. Device identity and credentials are stored in DSH_HOME.

The boundary is stated just as plainly: the account, device directory, signaling and relay currently come from a third-party service at dsh.r2049.cn, and the project says it does not yet offer a supported self-hosted server. Independent password security review, real two-machine cross-network testing and long-term stability validation are listed as incomplete. Existing profiles get this bundle added once on upgrade; if you disable or uninstall it, later app updates will not restore it.

Where DSH Desktop is the wrong tool

Platform coverage is the first hard limit. There is no official Linux package and no macOS Intel package. If your team standardizes on Linux workstations, this project is not an option today, and running from source means you own the build.

The remote feature is the second. It is on by default in new profiles, but it routes through a third-party account and relay service, and the README itself flags the missing independent security review. If your policy forbids third-party identity or relay services in the development loop, you must remove the bundle and accept that mobile continuation is gone. The project does not offer a supported self-hosted server, so there is no middle path.

The third limit is upstream coupling. The app tracks a trial line (DSH 0.1.5-rc.1) and a specific remote plugin version. A release candidate runtime means behavior can move under you between DSH releases, and the desktop distribution can only follow. Anyone who needs a frozen, long-term-supported agent runtime should look elsewhere.

Finally, the README does not document rollback. Update flow is described as a right-corner button that shows a changelog on hover and only downloads, pre-checks the profile and installs after a click, with a recovery page when the profile or client fails. What happens if you want to return to the previous version is not covered.

How this differs from assembling the official DSH Web app yourself

The real alternative is not another desktop agent. It is installing the official DeepSeek Harness npm runtime and dsh-web-app yourself and managing bundles through the dsh plugin CLI.

That path gives you full control over which versions you run and when you upgrade. It also gives you the work: resolving bundle compatibility, deciding what belongs in the profile, and handling the case where a plugin you removed reappears or a profile gets rewritten by a bad upgrade. DSH Desktop's answer to those problems is the fixed offline artifact for new profiles, the no-rewrite rule on normal startup, and a read-only profile pre-check before an app update.

The difference in approach is therefore about who owns the profile. Upstream hands you the runtime and the primitives. DSH Desktop hands you a curated starting state plus a desktop host, and in exchange you accept its release cadence, its platform list, and its default bundles. Neither is strictly better; they fail in different ways. Self-managed installs fail when you misconfigure the profile. The bundle edition fails when you need a platform or a plugin combination the maintainers have not pinned.

Licence, maintenance and upgrade cost

The repository is MIT licensed, and the README shows an MIT badge. The Electron host and the project's own code fall under that. The bundled runtime is the official DeepSeek Harness npm runtime and the official dsh-web-app, and the two default bundles are separate upstream projects with their own licences: ds-harness-remote and @vibeinging/dsh-session-teams. The repository carries a THIRD_PARTY_NOTICES.md and a legal/ directory, which is where the actual attribution and any per-bundle terms would be recorded. Read those before redistributing a build; this is not legal advice, and MIT on the wrapper does not relicense what it wraps.

On maintenance: the last push was on 2026-09-10, and v0.2.2 was released the same day, with v0.2.1 on 2026-09-03 and v0.2.0 on 2026-08-28. The repository is not archived. The release spacing suggests a fast cadence, but the README's own caveats about unfinished security review and stability validation are the more useful signal for planning.

The upgrade cost is mostly profile pre-checking and the pinned remote bundle. Because the app only pre-checks the profile read-only before updating and does not restore bundles you removed, an update is low-risk for your plugin choices. The recurring cost is keeping your own plugins compatible with a runtime that follows a release-candidate line, and re-verifying the remote bundle version whenever the DSH line moves.

Editorial conclusion

Adopt it if you want the official DSH Web session loop plus a files, Git and terminal workbench without assembling bundles yourself, and you are on macOS Apple Silicon or Windows x64. Skip it if you need a Linux or Intel Mac installer, if you want to self-host the remote relay, or if you will not accept a third-party account service in the loop. Verify first that the pinned DSH 0.1.5-rc.1 runtime and the bundled [email protected] match your security review, and check the release page for the artifact your platform actually ships.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. vibeinging/dsh-desktop on GitHub