DSH-Desktop-EAC: a desktop shell for DeepSeek Harness with a bundled Node.js runtime

What DSH-Desktop-EAC actually wraps

The project describes itself as a desktop client that encapsulates the official deepseek-ai/deepseek-harness. That framing matters, because it sets the boundary of what the maintainers own. The dsh kernel is upstream; DSH-Desktop-EAC supplies the window, the runtime, the plugin profile and the surrounding tooling. The README states plainly that EAC does not modify the official dsh kernel and preserves the upstream plugin architecture.

The intended user is someone who already runs the dsh CLI or wants to, but does not want to prepare Node.js, npm and a terminal first. The README's comparison table lists the default experience as needing a self-prepared Node.js and CLI startup, against a bundled Node.js, npm CLI and dsh with installer and portable builds on the EAC side. A second group is served by the plugin market: the README describes search, one-click install, uninstall and plugin management from inside the app, plus importing configuration from Claude Code and Codex.

One structural decision is worth naming early. The desktop client runs a separate web-desktop profile for plugins while sharing sessions and API keys with the CLI through DSH_HOME. That is a deliberate split: the same conversation history, a different plugin environment. If you have ever broken a CLI plugin set by installing something from a GUI, this is the design choice you are paying for.

The Tauri shell, the bundled runtime and the DSH_HOME split

Since 5.2 the desktop build uses a Tauri shell, meaning a Rust host process rather than Electron; the README notes the earlier v4.4.1 Electron build is retired and kept only as a release archive. The repository layout reflects this: there is a tauri-shell directory alongside dsh-desktop, and the Windows assets are NSIS installers and portable zips rather than an Electron builder output.

The runtime story is the part that removes the most setup work. The README states no pre-installed Node.js or other runtime is required, because Node.js, the npm CLI and dsh ship inside the package. That is why the Windows installer is around 191 MB and the portable zip around 228 MB. You are trading disk space for the absence of a toolchain prerequisite.

Data flow follows DSH_HOME. The desktop client and the CLI share the session store and API key there, while the desktop side keeps its own plugin profile. The README also notes the launcher companion project, DSH EAC Launcher, gives each instance its own program directory and DSH_HOME, which is the supported way to run more than one isolated setup rather than trying to multiplex a single home directory.

Around the kernel sit the reliability features: snapshotting before install and startup, a health check, repair, retry, rollback and incident reporting. These are described as automatic. The repository does not document the snapshot format or where snapshots are stored, so treat rollback as a feature you should verify on your own data before depending on it.

Installing on Windows and running a first session

The README points at the Releases page rather than a package manager. For the 5.x line the two Windows assets are an NSIS installer and a portable zip. Download the one you want from the release page, and check it against the SHA-256 file published alongside the release before running it.

The portable build needs no install step. Unzip it anywhere and run the executable; the README states data follows the program directory, which is what makes the portable build movable between machines or USB drives.

# portable build, after unzipping the release archive
Deepseek-Harness-EAC-5.3.6-portable.zip
Deepseek-Harness-EAC-5.3.6-Setup-x64.exe

For the installer build, run the NSIS executable. It installs to the system and creates shortcuts. The README notes a SHA256 checksum file is provided with the release, so the verification step is a file comparison rather than a manual hash hunt.

On first launch the app starts the bundled dsh kernel itself; the README's one-click startup claim is about exactly this, and there is no separate command to run. Sessions and API key are read from DSH_HOME, so if you already have a CLI setup, your existing conversations should appear rather than a blank state.

# shared state location, per the README
~/.dsh

The README also states that from v5.4 the single desktop distribution asks at install time whether you want the full or slim variant. The slim variant only disables peripheral plugins (desktop pet, phone bridge, multi-agent) by default, and the settings screen can re-enable them without reinstalling. If you are on 5.3.6, that choice does not exist yet.

The AIO package is a separate product, not a bigger download

DSHEAC AIO is easy to misread as the same app with more bundled. The README describes it as an All-in-One personal terminal that is independent of the 5.x mainline, with its own app data and its own dsh-home, deliberately not reading data from 5.x, v4Lite, the old EAC builds or the CLI. It can be installed alongside the mainline without conflict.

The isolation has a practical consequence: your CLI sessions and API key will not be there. The AIO portable build writes into a .dsh-aio-data directory next to the executable, which makes it self-contained and easy to move, and also means nothing is shared with the setup you already have.

The AIO line has its own version numbers and its own update channel. The README states the AIO updater is isolated from the mainline updater. At the time of writing the releases list shows an alpha channel (aio-v6.9.3-alpha.1) alongside a stable aio-v1.2.0, so the AIO branch is running two tracks at once. If you want one directory of state and no ambiguity about which build owns it, the mainline 5.x line is the simpler choice.

Where DSH-Desktop-EAC gets in the way

The most concrete limitation is signing. The README states the installer is not Authenticode-signed and that SmartScreen may warn about an unknown publisher, with the recommendation to verify the SHA-256 before running. For a managed Windows fleet this is usually a blocker, not an inconvenience.

The second is platform coverage. Windows 10 and 11 on x64 are the documented target; macOS 13 and later is listed for Apple Silicon only. There is no documented Intel Mac build and no Linux build. If your team is mixed-platform, the desktop client is not the common denominator.

The third is the project's own state. The README carries an important notice that the project is undergoing a major refactor, that external issues and PRs are not accepted during that period, and that remaining v5 bugs will not be fixed because v6 is intended to replace v5. The releases list shows an alpha v6 tag on the AIO line. So the stable-looking 5.3.6 is a line the maintainers have said they are winding down. That is not a reason to avoid the software, but it is a reason not to build a workflow that depends on a specific v5 behaviour surviving.

Finally, the plugin safety features are described but not specified. Snapshot timing, rollback scope and what the health check actually inspects are not documented in the README. Until you have triggered a rollback yourself, treat the guarantee as unverified.

How it differs from running dsh in a terminal or an IDE

The real alternative is the upstream deepseek-harness itself, run from a terminal after installing Node.js. That path gives you the kernel without the shell: no bundled runtime, no plugin market UI, no snapshot and rollback layer, and no 10 built-in themes. It also gives you the upstream issue tracker and release cadence, which matters more than any UI feature if something breaks in the kernel.

The second alternative is the project's own Deepseek Harness EAC IDE, which the README promotes as a standalone IDE with EAC built in. The README also states the IDE has entered maintenance mode, so it is not a forward-looking choice; the README frames the desktop client as the sole desktop distribution from v5.4 onward.

The third is the DSH EAC Launcher, which is not a competing client but a different layer. It handles multiple isolated instances, importing local instances, one-click version upgrade and rollback, and the plugin safety system including crash-guard, plugin snapshot rollback, quarantine and health checks. If your problem is version pinning or recovering a broken plugin set, the launcher addresses it directly. If your problem is that you do not want to install Node.js, the desktop client does.

Choosing between them comes down to what you are optimizing for. Terminal plus upstream dsh is the least mediated and the most supported. The desktop client is the least setup. The launcher is the most controllable across versions.

Licence and what an upgrade actually costs

The repository is MIT licensed, and the README carries an MIT badge linking to the LICENSE file. MIT is permissive: you can use, modify and redistribute the code, including commercially, provided the copyright notice and permission notice are retained. The bundled Node.js runtime and the upstream dsh kernel may carry their own licences, and the README does not enumerate them, so if you redistribute a packaged build rather than using it internally, check the licence files of the bundled components yourself. This is a description of the licence, not legal advice.

Upgrade cost is where the project's structure shows. The README states the dsh agent and the desktop client check for updates separately, and that a failed update keeps or rolls back to the previous version. Two update channels means two things to keep in step, and it means a kernel update and a shell update can land at different times.

The larger cost is the v5 to v6 transition the README announces. The README says v6 will replace v5's functionality as soon as possible and that remaining v5 bugs will not be fixed. Combined with the freeze on external issues and PRs, this means the normal escape hatch for a bug you hit is closed for the duration. Budget for that: pin the version you deploy, keep the installer or portable archive you validated, and do not assume a fix will arrive for anything short of a v6 replacement.

For the mainline, the README points to docs/SINGLE-EDITION-MIGRATION.md for the consolidation of the former Lite and AIO editions into one installer with full and slim options. That document is the one to read before moving an existing installation, not the release notes.

Editorial conclusion

Adopt DSH-Desktop-EAC if you already use the dsh CLI on Windows and want the same sessions and API key in a window, without installing Node.js yourself. Skip it if you need a signed installer, a stable release line, or a way to file bugs: the README states the project is mid-refactor and not accepting external issues or PRs, and v5 fixes have stopped. Before installing, verify the SHA-256 of the downloaded asset and check whether the Tauri 5.x line or the separate AIO package matches the data directory you intend to keep.

Frequently asked questions

Official sources

1. DSH-EAC/DSH-Desktop-EAC on GitHub
2. License: MIT
3. Project website
4. README
5. Releases