# DSH Desktop: the window, the tray, and the update check as plugins

> DSH Desktop wraps a pinned build of DeepSeek Harness in a native Windows and macOS client and treats its own shell as a plugin, so the desktop is composed through the same mechanism third party plugins use. The interesting parts are its edges: a LAN mode with no authentication at all, an update check that identifies machines by a locally generated UUID, and a dependency tree carried as patched tarballs in vendor/.

**anywhere-labs/dsh-desktop** — 为 DeepSeek Harness (DSH) 插件生态打造的现代化桌面端解决方案。万物皆「插件」，桌面本身也是「插件」。

- Repository: https://github.com/anywhere-labs/dsh-desktop
- Website: https://dshdesktop.cn
- Stars: 29,641 · Forks: 1,416
- Language: TypeScript
- License: MIT
- Published: 2026-09-16 · Updated: 2026-09-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/anywhere-labs-dsh-desktop

## The desktop shell is itself a plugin, and that is the whole design

DSH Desktop does not modify the upstream source. A specific upstream version of DeepSeek Harness is pinned and runs as it is, and the shell, meaning the window, the tray, the terminal, updates and work profiles, is attached as a DSH plugin and composed into the same runtime through the mechanism upstream provides. The project states this plainly and also says the project itself is a DSH plugin, using the same composition mechanism as third party code. Two consequences follow. Plugin compatibility is defined against the pinned upstream version rather than against Harness in general, so a plugin built for a different version is not automatically usable here. And the boundary of ownership is explicit: upstream supplies the core agent capability, the plugin system and the Web UI, while this project handles desktop packaging, starting, stopping and recovering the local service, window and tray integration, installer builds, and a desktop oriented interface. If you want a command line Harness or want to work on the core, the project tells you to go upstream.

## Enabling LAN access hands the machine to the network with no authentication

The web service listens on the loopback address only, by default. LAN access is a separate optional setting, and when you turn it on the desktop settings panel shows the current LAN URL so you can see what you exposed. The project attaches an explicit warning to this feature: opening to the LAN provides no authentication, and everyone on the same network can open DSH and operate your computer. That is not a theoretical caveat, it is the documented behaviour of the mode. It also interacts with a second setting in a way worth reading carefully, because opening in the browser and widening network exposure are separate. The browser option hands the URL to the system default browser once the web service is actually ready, and it does not change how far the service is exposed. If your threat model involves an office network, a hotel, a conference, or a shared flat, the safe configuration is the default one and this switch stays off.

## The version check identifies your machine, the package download does not

The fixed version check request is specific about what it sends. The current installed version travels in the X-DSH-Desktop-Version header, the channel travels as stable or beta in X-DSH-Desktop-Channel, and X-DSH-Desktop-Installation-Id carries a random UUID generated on the machine and persisted there, which the project states explicitly is not derived from hardware information. The package download is narrower on purpose. It carries the channel and an X-DSH-Desktop-Target-Version header, but the download request and its redirects do not carry the installation identifier or the current version. Read together, the two requests are separable on purpose: a check can be attributed to a specific persistent install, while a fetch is a plain target version request that follows redirects without dragging the install identity along. If you care about what leaves your machine during an update, that header list is the part to audit, and the project is unusually explicit about the boundary.

## Three releases cut on one day means three different latest builds

On 29 September 2026 the project published v2.0.17, v2.0.17-beta.1 and v2.0.17-next, three artifacts sharing one version number and cut within a minute of each other. The same three way split is mirrored in the source layout, where the workspaces include dsh-plugin-desktop, dsh-plugin-desktop-beta and dsh-desktop-next. The channel is the thing that tells them apart, and it is also the value sent in the X-DSH-Desktop-Channel header, which means the choice is made at update time rather than baked into the installer name. The practical consequence is that asking for the latest version is an incomplete question. There is a stable build, a beta build and a next build for the same version, and only the channel field resolves the ambiguity. Decide which lane you are in before you rely on automatic updates, because a client that follows stable and one that follows next will report the same version number and behave differently. The last commit on the repository is dated 30 September 2026, so all three lanes were moving at once.

## The Setup Wizard blocks the Host and the main window until it is answered

Every profile that has not been initialised shows a native Setup Wizard on first launch, supplied by the desktop itself rather than by the upstream web UI. The wizard can set window mode and system material, the plugin market, notifications, whether to auto open in the system default browser, and the scope of web access, and it can also be skipped outright. The rule that matters is the sequencing: until the wizard is either completed or skipped, the Host and the main DSH window do not start at all. Completion and skip are recorded per profile, so one machine with several profiles can be in a different state for each, and an explicit restore launch still goes to the recovery assistant first. For anyone automating this or provisioning a fresh profile, that gate is the thing to handle, since a silent install produces an application that appears to launch and then does nothing.

## Upstream comes from a submodule and runtime packages come from vendor tarballs

The dependency setup is unusual enough to look at before you try to build. The repository carries .gitmodules and an upstream.json, so the pinned DeepSeek Harness arrives as a git submodule rather than as a package from a registry. The DeepSeek runtime packages are pinned to release candidate versions and are served from local tarballs, with dsh-brand and dsh-invariants both at 0.2.0-rc.2 referenced by file path under vendor/. Everything else is held in place with the resolutions field, which rewrites app-builder-lib, open, fs-ext, pnpm and @vscode/ripgrep to patched builds and pins koffi to 3.1.5, each pointing at a patch file under patches/. The upside is a build that resolves the same way on your machine. The cost is that you cannot simply bump a dependency, because the patch stops applying and you have to carry the change forward yourself, and pre release runtime versions mean the pinned base is explicitly not final.

## A narrow Node range and Yarn 4 gate anyone building from source

The root package.json names the product workspace deepseek-harness-desktop, marks it private, and declares yarn@4.18.0 as the package manager with an engines field of ^22.19.0 || >=24.0.0. Five workspaces sit under it, covering the desktop plugin, the beta plugin, the next line, the community fabric and the community market. None of that reaches you as an end user, because the shipped installers require no extra environment at all: Windows x64 gets an NSIS installer you run, macOS gets a Universal DMG you drag into Applications. It matters only if you build from source, and there the constraints are narrow. Node 20 does not satisfy the range, Yarn 4 is the required package manager rather than whatever ships with your machine, and there is no published package to install because the root is marked private. So the source build is a contributor path, not an alternative distribution channel.

## The plugin market accepts public Schema sources and reviews adapters for legacy APIs

The DSH Community Market is built in and handles discovery, details, installation and management. Its connection model is open by schema rather than open by listing: anyone can supply, connect and use a source that conforms to the published Schema, and an existing API can join as a partner source through a reviewed adapter. That two path design is the mechanism worth understanding. Conforming to the public Schema is self service, so the long tail can arrive without anyone gating it, while a service with its own shape needs a reviewed adapter, which is a human process with a queue. The consequence for a user is that the market's coverage is a function of both how many plugin authors meet the Schema and how many legacy services someone has reviewed, and the two do not grow at the same rate. Plugin authors can also reach desktop capabilities directly, including viewing and switching work profiles and installing, updating and removing plugins within the current profile.

## Conclusion

Adopt it if you want DeepSeek Harness in a native window with a tray, installers and a plugin surface, and you are willing to treat the upstream pin as a fixed contract rather than a moving dependency. Leave it if you need a hardened multi user network exposure, or if you intend to run the agent core from a command line, since the project itself points those users upstream. Before you install, decide three things: whether you will ever touch the LAN setting, which release channel you actually want, and whether the plugins you rely on are compatible with the pinned upstream version rather than with Harness in general.

## FAQ

### Does DSH Desktop need Node.js or a command line to run?

No. The released installers need no extra environment: Windows x64 users run an NSIS installer, and macOS users open a Universal DMG and drag DSH Desktop into Applications. Building from source is a different story, since the root package.json requires yarn@4.18.0 and a Node engine range of ^22.19.0 || >=24.0.0.

### Is it safe to turn on LAN access in DSH Desktop?

The project states that opening the service to the LAN provides no authentication, and that everyone on the same network can open DSH and operate your computer. The web service listens on the loopback address by default, and LAN access is a separate optional setting, so the documented advice is to enable it only on a fully trusted network.

### Who builds and maintains DSH Desktop, and is it connected to DeepSeek?

It is an independent community project with no DeepSeek employees and no members of the upstream DeepSeek Harness team taking part in its development, maintenance or governance. Upstream names visible on the contributors page come from fork inheritance and later synchronised commits, and the project is MIT licensed.

### Can I write my own plugins for DSH Desktop?

Yes, and the project describes itself as a DSH plugin using the same composition mechanism as third party plugins. Desktop services let a plugin work with desktop capabilities such as viewing and switching work profiles, and installing, updating and removing plugins in the current profile.

## Sources

- [anywhere-labs/dsh-desktop on GitHub](https://github.com/anywhere-labs/dsh-desktop)
- [License: MIT](https://github.com/anywhere-labs/dsh-desktop/blob/master/LICENSE)
- [Project website](https://dshdesktop.cn)
- [README](https://github.com/anywhere-labs/dsh-desktop/blob/master/README.md)
- [Releases](https://github.com/anywhere-labs/dsh-desktop/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/anywhere-labs-dsh-desktop