DSH-X is a desktop launcher that leaves the DeepSeek Harness UI alone

It launches the official page and manages everything around it

DSH-X is described as a third-party lightweight desktop launcher for DeepSeek Harness, and the important clarification comes first. DSH-X starts the official original DeepSeek Harness web page. It only handles version installation, launching and plugin management, and it does not modify or rebuild the DSH web interface. DSH-X itself is a community open source project and not an official DeepSeek product.

That constraint defines the whole product. Everything in the feature list is about the environment around the application rather than the application itself: which version runs, which profile it uses, which port it listens on, what plugins are installed, and how the window is presented.

For a user who wants the official interface with several independent configurations, this is a reasonable division of labour. For a user who wanted a re-skinned or extended interface, it is the wrong tool, and no amount of configuration will change that.

The project is written in JavaScript and packaged as an Electron-style desktop application, with a package.json that names the package dsh-versions, the product DSH, and sets the engine requirement to node >=22.18.0. The homepage is a GitHub Pages site, and the README links an English translation at README.en.md.

The feature set splits cleanly into six areas: launch entries and multiple instances, version management, plugins and modpacks, MCP and skills, several ways of opening the interface, and updates with recovery.

Launch entries carry a profile, a version and a port each

The first feature area is launch entries and multiple instances. Each entry selects a user directory, a profile, a version and a port, parallel launching is supported, and entries can be added while a session is already running.

That is the core of the product. A user who works on two projects with different plugin sets does not want one shared configuration directory, and a user who wants to test a new version of DSH without disturbing a working one needs separation. Per-entry profiles and versions give that separation, and the port assignment per entry is what lets two instances run at the same time without colliding.

The management page has a default port of 3780, and the documentation states that when that port is taken the next one is used. Sequential fallback is a small detail, but it matters in a setup where a development instance and a packaged instance are often both running.

The port also appears in the access story. To reach dsh from a phone or another computer, the documentation describes a Web binding option under the advanced settings, where you select LAN, and it takes effect on the next start. That is a deliberate step rather than an immediate switch, which is the safer default for a service that exposes a web interface.

The interface itself can be presented in four ways: a tab inside DSH-X, a tab in the system browser, a standalone browser window, or a desktop window. The internal tab requires the installed desktop client, since it is not just a browser pointing at a port.

Versions are installed, detected and cleaned up separately

Version management is the second area, and it is more than a version display. Installed versions are managed independently, the tool can detect new versions, install and uninstall manually, and each launch entry can be pointed at a specific version.

Pointing an entry at a specific version is the feature that makes the rest useful. It is the difference between testing a new DSH build and having that build change under you while you work.

Updates and recovery are grouped with it. There is self-update, fault recovery, and a configurable number of old versions to keep, with the versions currently in use by a launch entry and the one it used previously kept in addition. That last rule is the sensible one: the previous version is the rollback target, and a cleanup policy that deleted it would remove the safety net at the same time as the clutter.

Nothing in the documentation claims that the version detection knows about every distribution channel of DSH, and the manual install path is the fallback for anything automatic misses. The documentation is explicit that the version manager is also reachable from the launch entry editor, where you can install or uninstall versions directly.

Modpacks install in .dspack format with backup and rollback

The third area is plugins and modpacks, and it is the most involved part of the product.

Plugins are installed per environment, can be switched on and off, and can be updated. The default index source for the official custom plugin marketplace is configurable, which matters for users who mirror that marketplace. The community modpack market supports waterfall browsing, search and sorting, and modpacks can be imported and exported.

A modpack installs a set of plugins and configuration into a chosen environment, which the documentation calls a profile. The plugin page shows the plugins per environment, and an environment that has a pack installed is marked with its source, while individual plugins can still be toggled independently. The format is the .dspack format from the DSH-PackForge project, using manifest v5 and staying compatible with older versions.

Four import routes exist: the community market, a local file, a direct link, or a GitHub owner/repo reference. The default is to install into the currently selected environment, and the target can be changed before confirming.

The install flow is the part worth reading carefully, because it is where the risk lives. You first review the plugin and file changes, then confirm. A backup is taken before overwriting, and a failed install rolls back automatically. Export produces a .dspack from the current environment's dependencies, patch layers and configuration, and deliberately excludes node_modules and credentials, so a shared pack does not carry your tokens.

The repository ships a recommended pack recipe at packs/dsh-x-recommended/manifest.json, containing configuration management, memory, sync and decoration plugins, all installed from npm, with sync provided by an optional plugin named dsh-x-sync. You can generate a pack with node scripts/make-pack.mjs and then import it as a local file.

MCP servers and skills are configured in the same app

The fourth feature area is MCP and skills, which the documentation summarises in one line. MCP servers can be configured, and skills can be imported, managed and switched on and off.

The interesting part is the relationship to the environment model. A plugin is installed into a profile, and an MCP server or a skill is part of that same per-environment configuration, which is why the modpack export includes the environment's dependencies, patch layers and configuration. Pack it once and the MCP servers and skills travel with it.

The repository layout reflects that the whole feature set is implemented in plain Node modules at the top level rather than inside a src directory. There are mcp.js, skills.js, plugins.js, packs.js, pack-market.js, plugin-tool.js, settings.js, version.js, sync.js, proxy.js, registry.js, recovery.js, zip.js, zipfile.js and platform.js, alongside launcher/, installer/, compat/, perf/, plugins/, skills/ and packs/ directories and public/ for the interface assets.

The proxy.js module is worth noticing for a different reason. Since the launcher starts the local DSH web interface and then presents it, something has to forward the local port to whatever the user actually opens, and that is what a proxy module in the tree is for. The documentation does not describe its configuration surface, so anyone who needs to change how traffic is forwarded is reading code rather than docs.

The installer is not Authenticode signed, and that is stated plainly

The section on signing and antivirus false positives is short and unusually candid.

The signature in the release manifest is used to verify file integrity, and it is different from a Windows publisher signature. DSH-Setup.exe has not been Authenticode signed, which means Windows SmartScreen may show an unknown publisher warning. The documentation points at the Microsoft submission portal and at antivirus vendors for appeals if the installer is flagged as a false positive.

This is the main operational risk of the project, and it is not a small one for a tool that manages plugin execution and MCP servers on a developer machine. SmartScreen warnings on a fresh download are the single most common reason people abandon a project like this.

The macOS side has an equivalent caveat. Version 0.1.18 uses a temporary signature and is not notarised, so the first launch may require manually allowing the app in the system security prompt.

The mitigation offered for both is verification. Each file on the release page has a sha256 next to it, and the documentation shows the local check for each platform, using certutil on Windows and shasum on macOS. The release manifest also carries a private key at release/release-key.pem, which is ignored by git, does not go into the repository, and is flagged in the documentation as something that must be backed up. Losing that key means losing the ability to sign future manifests, and it is the kind of operational detail that is much cheaper to handle now than later.

Building and releasing from Node with no third-party dependencies

The development section is short, which is itself informative. A local machine needs Node.js 22.18 or newer and there is no need to install third-party dependencies. npm start launches the management page, npm run server starts only the service, and npm test runs the tests.

The package scripts confirm the shape of the project.

  "scripts": {
    "start": "node start.js",
    "server": "node server.js",
    "test": "node --test",
    "dist": "node scripts/pack.mjs",

The test runner is the built-in node --test, and the build is a plain Node script rather than a bundler. The absence of third-party dependencies is a real constraint on the project and it also removes the supply chain surface that a launcher of this kind would otherwise add.

Packaging is platform specific. The dist script is npm run dist.

npm run dist

On Windows, which needs Rust and Inno Setup 6, it produces a portable release/DSH directory and a release/DSH-Setup.exe installer. On macOS, which needs Rust and the Xcode command line tools, it produces release/DSH-X.app and a release/DSH-X-mac-<arch>.dmg, with the Intel build selected through the DSH_MAC_ARCH=x64 environment variable.

The Windows packaging step also generates an SBOM and a release manifest for local checking, and those are not uploaded to the release. Before shipping, the version and the artefacts are checked with two commands.

node scripts/release-manifest.mjs check-tag v0.1.18
node scripts/release-manifest.mjs verify

The GitHub Actions build workflow can produce installers for all three platforms, and the documentation says to publish only once all of them are present. Tagged macOS builds require a fixed certificate configuration described in docs/mac-signing.md, and without that configuration a manual build falls back to the temporary signature.

Editorial conclusion

Use DSH-X if you run DeepSeek Harness locally on Windows or macOS and want several isolated profiles, managed versions and a plugin and modpack workflow without hand-editing files. Do not adopt it expecting a modified interface, because the launcher starts the official web page unchanged, and treat the unsigned installer as the main operational risk on Windows. Before installing, check the sha256 published next to each release file, and on macOS expect a Gatekeeper prompt because the app is signed temporarily and not notarised.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. yyh-001/DSH-X on GitHub