DSH Desktop: a Windows and macOS client that bundles the DeepSeek Harness runtime
DeepSeek Harness (dsh) Windows desktop client - bundled Node.js + dsh CLI, one-click launch
At a glance
- What is it?
- DSH Desktop packages the dsh CLI, an independent Node runtime and the official plugins into a Tauri 2 desktop shell, so a user can double-click instead of installing Node.js. The trade-off is that the whole kernel ships with the client, which removes one update path and creates another.
- Who is it for?
- Adopt DSH Desktop if you want the DeepSeek Harness running on a Windows 10 or 11 machine without touching Node.js, and if you accept that the kernel moves only when the client moves. Do not adopt it if you need a signed macOS build, a Linux package that the README documents, or a separately upgradable dsh core.
- 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 last received commits 3 days ago.
- 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 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What DSH Desktop solves, and for whom
Running the DeepSeek Harness normally means having Node.js on the machine, installing `@deepseek-ai/dsh` and its plugins, and starting a web server from a terminal. The README frames the desktop client as the answer to that first step. It bundles an independent Node runtime and the npm CLI, so the target machine needs no environment at all, and a double-click starts `dsh web` and loads the result into a native window. The README describes the packaged set as `@deepseek-ai/dsh` plus all official plugins, usable offline.
The audience is therefore narrower than "anyone curious about dsh". It is people who already use the Harness, or want to, and who would rather not maintain a Node toolchain to do it. The README also lists a portable build that can live on a USB stick and an installed build that creates desktop and Start menu shortcuts. If you are comfortable with `npm install` and a terminal, the desktop shell adds window chrome, a tray icon and notifications rather than new agent capability.
The Tauri 2 shell and the guardian waterfall
The desktop shell is not Electron. The README states that v0.5.0 moved the shell from Electron to Tauri 2, which is Rust, and that the Electron line is no longer maintained. The repository layout matches that claim: `dsh-tauri/` holds the Rust side and `dsh-desktop/` holds the payload source that the Tauri build consumes. The README describes the release pipeline as vendoring node v24.15.0, running `stage-payload.sh`, and building a compatibility layer with fail-fast behaviour.
The mechanism worth understanding is what the README calls the guardian waterfall. The boot chain is designed to self-heal level by level: a broken plugin is repaired automatically, a broken configuration is rebuilt automatically, and a kernel crash loop is restarted in place rather than terminating the app. The stated goal is that no incompatible state leaves the user staring at a blank window. A second layer watches the renderer with a heartbeat and reloads it if it stalls, while a supervisor probes the kernel and restarts it with exponential backoff.
That is a deliberate design stance. Instead of surfacing a configuration error and refusing to start, the client prefers to repair and continue. It reduces the number of hard failures and raises the number of silent recoveries, which is a reasonable trade for a desktop app whose users are not expected to read logs. The README also mentions patching the session event vocabulary so that events written by third-party plugins do not corrupt conversation history.
Installing DSH Desktop and starting a first session
The README points to GitHub Releases for the current Tauri build and says the system requirement is Windows 10 or 11 on x64, with no Node.js prerequisite. Download the installer for your platform from the Releases page and run it. The README states that the NSIS installer uses `currentUser` mode, so it does not need administrator rights, and that the WebView2 bootstrapper is embedded so an offline machine can still install.
The README gives one direct download link for the v0.5.0 Windows x64 installer, which it describes as roughly 87 MB. If you are upgrading from an Electron build in the 0.1.x to 0.4.x range, the README says the installer locates the old directory, silently uninstalls it while keeping data, and installs back into the same location. That behaviour is documented in the migration guide under `dsh-tauri/docs/upgrade-guide.md`, not in the README itself.
xattr -dr com.apple.quarantine "/Applications/DSH Desktop.app"The README notes that macOS builds are unsigned, so Apple Silicon users see a developer verification warning on first launch. Right-clicking the app and choosing Open is the documented alternative to the command above. After the window opens, the client starts `dsh web`, prefers the port used last time, and loads the native window once the server reports ready. The README lists the default data locations: next to the executable in `data\` for the Windows portable build, `%APPDATA%\DSH Desktop\` for the installed build, and `~/Library/Application Support/DSH Desktop/` on macOS. Setting `DSH_HOME` overrides the dsh configuration directory. If you are moving from a portable copy to an installed one, check which of those two paths your sessions actually live in before you assume the upgrade carried them over.
Where the desktop wrapper gets in the way
The kernel is distributed with the client. The README states this explicitly: there is no separate update chain for the kernel. That means a new dsh release or a new official plugin does not reach you until a new client release ships and you install it. If you track dsh closely, or you need a plugin version that landed upstream yesterday, the desktop client is the slower path and a plain npm installation is the faster one.
The update mechanism is also constrained by where the binaries live. The README describes client updates as pulling from GitHub or Gitee Releases with automatic source switching and sha256 verification that fails closed. That covers the client. It does not give you a way to pin the kernel to a version while letting the shell move, because the two are one artifact.
The platform story is uneven. The README says the v0.5.0 release produced a Windows x64 NSIS installer, and that from v0.5.1 the pipeline produces six assets across Windows, Linux AppImage and deb, and macOS dmg, with the 0.5.x line marked as prerelease. The Gitee mirror is a separate problem: the README notes that Gitee currently carries only the Electron v0.4.1 build, not the Tauri packages, so users who rely on that mirror are effectively on the retired architecture. The README does not document a rollback path from a Tauri install back to an Electron one beyond downloading an older release.
How it differs from running dsh web yourself
The real alternative is not another desktop app. It is the upstream `dsh web` workflow: install Node.js, install `@deepseek-ai/dsh` and the plugins you want, run the command, and open the URL in a browser. The difference is who owns the runtime. With the manual route you choose the Node version, you choose when the kernel moves, and you can add or remove plugins without waiting for a client release. You also get a browser tab instead of a native window, no tray icon, no completion notifications, no side session window, and no balance widget.
The README's own comparison table draws that line: archive-only session handling in native `dsh web` versus archive, restore and delete in the desktop client; no balance display versus a per-turn cost and balance readout that also covers OpenCode Go subscription quota. Those are shell features, not agent features. If your work happens inside the conversation and you never look at the window frame, the manual route costs you nothing and keeps your upgrade cadence in your own hands. The desktop client earns its place when the machine is shared, when the user is not a developer, or when you want the Harness to survive a bad plugin without a terminal to fix it.
Licence, maintenance and the cost of upgrading
The repository is MIT licensed, and the README states that the packaged runtime includes `@deepseek-ai/dsh` and official plugins. MIT covers the client code. It does not automatically cover every bundled dependency, and the repository carries a `THIRD_PARTY_NOTICES.md` file for exactly that reason. If you redistribute the installer inside an organisation, read that file rather than assuming the top-level licence settles the question. Nothing here is legal advice.
The last push to the repository was on 2026-09-15, and the most recent release listed is v0.6.4 on the same day, with v0.6.3 on 2026-09-09 and v0.6.2 on 2026-09-05. The repository is not archived. That cadence is the maintenance cost in practice: releases arrive often enough that the auto-update path will fire regularly, and each one replaces the whole kernel. The upgrade itself is designed to be cheap. The README says the installer reinstalls into the previous location and that user data is fully compatible across the Tauri migration, and it mentions self-healing shortcuts for the desktop and Start menu. The cost is not the install; it is that you cannot hold the kernel still while taking shell fixes, and you cannot take kernel fixes without a new client build.
Editorial conclusion
Adopt DSH Desktop if you want the DeepSeek Harness running on a Windows 10 or 11 machine without touching Node.js, and if you accept that the kernel moves only when the client moves. Do not adopt it if you need a signed macOS build, a Linux package that the README documents, or a separately upgradable dsh core. Verify first that a release exists for your platform in GitHub Releases, that your data directory is where the README says it is, and that the sha256 of the installer matches the published checksum before you overwrite an existing install.
Frequently asked questions
What does DSH stand for in DSH Desktop?
The repository describes dsh as DeepSeek Harness, and the desktop client is named after it. The README does not expand the abbreviation beyond that pairing.
Does DSH Desktop need Node.js installed?
No. The README states that the client bundles an independent Node runtime and the npm CLI, so the target machine needs no environment installed, and it ships `@deepseek-ai/dsh` with the official plugins for offline use.
Which platforms does DSH Desktop support?
The README states Windows 10 and 11 on x64 as the requirement. It also says that from v0.5.1 the release pipeline produces six assets covering Windows, Linux AppImage and deb, and macOS dmg, with the 0.5.x line marked as prerelease.
Where does DSH Desktop store its data?
The README lists `data\` next to the executable for the Windows portable build, `%APPDATA%\DSH Desktop\` for the installed build, and `~/Library/Application Support/DSH Desktop/` on macOS. Setting `DSH_HOME` overrides the dsh configuration directory.
Can I install dsh plugins into DSH Desktop?
The README says the official plugins are already packaged, and it describes the boot chain as repairing a broken plugin automatically rather than refusing to start. It does not document a procedure for adding a third-party plugin by hand.
Community notes