DSHCode: a desktop shell for DeepSeek Harness

What DSHCode is, and the problem it removes

DeepSeek Harness (the `dsh` package) is a plugin-based agent framework. Getting it running normally means a Node.js toolchain, a package manager, and a terminal session. DSHCode exists to delete that step. It is a community Electron application that bundles the Harness Web UI and the plugin runtime into an installer for macOS and Windows. The README states the goal plainly: no Node.js, no terminal, no command line for install-version users.

The audience is narrow and identifiable. It is someone who wants the agent core (bash, filesystem, web search and fetch, terminal, LSP, subprocess tools), the interactive GenUI cards, skills, subagents and workflows, but does not want to own a JavaScript build. That person gets a normal application window instead of a dev server.

The project is explicit that it is not an official DeepSeek product. It keeps upstream package names, copyright, architecture and documentation, and keeps an `upstream` Git remote so it can merge upstream changes, but the README says it does not represent an official release or endorsement unless DeepSeek authorises one.

How the Electron shell talks to the Harness runtime

The architecture is deliberately thin. On launch, DSHCode starts an HTTP service inside the Electron main process. That service binds to `127.0.0.1` only, and lets the operating system assign an ephemeral port rather than claiming a fixed one. The README gives the reason: no fixed port means less chance of colliding with another local service.

The window then loads that exact loopback address. The README says DSHCode loads only its own precise loopback address, and that it enforces a single application instance. On exit, the process releases the Harness tree before quitting, so closing the app stops the service and frees the port.

This is the part worth judging. The desktop shell is intentionally minimal; product behaviour and the Web UI still come from the upstream packages. That choice keeps upstream merges cheap, because there is no second interface to maintain. It also means the desktop layer cannot diverge far from upstream without losing its main advantage. Bug fixes and UI changes arrive when upstream ships them, not when the shell wants them.

A second consequence: the agent runtime runs locally, but model calls go out through the official DeepSeek API. The README says a key is required and is configured once in the app settings.

Installing DSHCode and running a first session

Install-version users do not build anything. You download the package for your platform from the GitHub releases page, run the installer, and open `DSHCode` from the macOS Applications folder or the Windows Start menu. The README lists three targets: `DSHCode-*-macos-arm64.dmg`, `DSHCode-*-macos-x64.dmg`, and `DSHCode-*-win-x64.exe`.

Each release publishes SHA-256 checksums in `SHA256SUMS.txt`. Verify the file you downloaded against that list before launching; this is the only integrity check the README documents for the installers.

Preview installers are not code signed or notarised, so Gatekeeper and SmartScreen can warn before the first launch. On macOS, the README gives a one-time workaround:

xattr -cr /Applications/DSHCode.app

On Windows, the README describes clicking More info in the SmartScreen dialog and then Run anyway. Neither step is needed on later launches.

Developers who want to run the upstream web entry from source instead use the workspace commands. The README gives this sequence, and notes that it prints the local Web UI address:

git clone https://github.com/whitelonng/dshcode.git
cd dshcode
pnpm install
pnpm run build
pnpm dsh web

To produce installers yourself, the desktop build script is `pnpm run desktop:dist`, and the README says artefacts land in `.artifacts/desktop/release/`. The `Desktop` GitHub Actions workflow builds the macOS Apple Silicon, macOS Intel and Windows x64 packages; a `desktop-v*` tag publishes the full matrix plus checksums to GitHub Releases.

The unsigned build is the real adoption cost

The most concrete limitation is signing. The README states that preview installers are not code signed or notarised, and frames it as a certificate cost rather than a security problem. That framing is fair, but the operational consequence is real: on managed macOS fleets, Gatekeeper prompts and the `xattr` workaround are policy events, not user convenience. On Windows, SmartScreen warnings in a corporate environment usually mean a helpdesk ticket.

There is a second boundary. DSHCode depends on the DeepSeek API. Without a key configured in settings, the agent has no model to call. Anyone expecting a fully offline local agent will be disappointed, and the README does not describe a local model path.

A third case where this is the wrong tool: if you already run `dsh` from source and are happy with the terminal, the desktop shell adds a layer you do not need, and you inherit the shell's release cadence on top of upstream's. The README itself points developers back to `pnpm dsh web` for that workflow.

The desktop guide under `apps/desktop/README.md` is where the README says architecture, platform targets and current limitations are documented. If you are evaluating this for a team, that file is the one to read before the FAQ.

DSHCode versus running DeepSeek Harness from source

The honest alternative is not another desktop agent. It is upstream DeepSeek Harness itself, installed from the repository and driven from the terminal.

The difference is where the abstraction sits. Upstream gives you the full workspace: the `pnpm` scripts, the build profiles, the test and lint configuration visible in `package.json`, and direct control over the version you run. DSHCode gives you a packaged Electron window, a tray icon, native notifications, single-instance behaviour, and a hardened window, at the price of the runtime being whatever the shell bundles.

For plugin authors the two are closer than they look, because DSHCode inherits the upstream plugin model. The README describes installing plugins from npm or a Git repository, checking for updates, and enabling or disabling them individually. It also describes a failure path: plugins that fail to load are reported with diagnostics, and you can disable the plugin, start in safe mode, or let the agent attempt a repair with the failure context. That repair flow is a desktop-shell feature, not something the README attributes to the upstream CLI.

So the split is straightforward. Choose upstream for control over versions and build flags. Choose DSHCode for the graphical workspace and the failure-recovery UI, and accept the packaging layer.

Licence, redistribution and maintenance signals

The source stays under the upstream MIT licence. The README states that redistribution must keep DeepSeek's copyright and licence notices, and that bundled third-party software and its licences are listed in `THIRD_PARTY_NOTICES.md`. Desktop installers ship both files alongside the app.

The README draws a line that matters for anyone repackaging this: the MIT software licence is not a trademark or logo licence. DeepSeek's terms of use reserve rights over those brand marks. DSHCode uses its own application icon, and the upstream identity marks retained inside the embedded Harness interface, plus the `powered by dsh` attribution, are described as compatibility statements rather than endorsement. If you plan to redistribute under your own brand, that distinction is the one to resolve with counsel, not with the licence file alone.

On activity: the repository is not archived, and the last push was on 2026-09-05. The most recent release listed is `desktop-v1.0.8` on 2026-08-29, following `desktop-v1.0.7` and `desktop-v1.0.6` earlier in August. Three releases in one month is a fast cadence for a packaging project, and it cuts both ways: fixes arrive quickly, but so does churn. The upgrade path is a fresh installer download, since the README documents no in-app updater and no rollback procedure.

Editorial conclusion

Adopt DSHCode if you want the DeepSeek Harness agent loop on a desktop and refuse to manage a Node toolchain, and if you accept an unsigned community build. Skip it if you need signed, notarised binaries for managed fleets, or if you want the upstream CLI and its own release cadence. Verify the SHA-256 checksum in SHA256SUMS.txt against your download before the first launch, and confirm the DeepSeek API key is configured in the app settings before you start a session.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. whitelonng/dshcode on GitHub