DSH Desktop Checks That Your Update Is a Real Installer, Not Who Built It

A third-party Electron client for DeepSeek Harness went from 225 stars to roughly 11,600 in four days. Its own docs name the gap in the update path, and that documentation is the best thing about it.

Buried in the Known Limitations section of DSH Desktop's packaging README is a sentence that took me three reads to fully appreciate. "The update handoff validates the download container, not publisher identity."

Translated: when the app downloads its own update, it confirms the file is a well-formed DMG or a real Windows executable. It does not confirm who built that file.

This is an Electron app that bundles its own Node runtime, its own pnpm, native modules including node-pty, and a pinned copy of an agent runtime that can execute shell commands. It polls a single vendor endpoint every six hours for a new version. And it says, in its own documentation, that the check on what comes back is structural rather than cryptographic.

The project wrote that sentence itself. Nobody found it in an audit. That level of self-disclosure is rare in a fast-growing repo, and it is why DSH Desktop deserves a careful look rather than a dismissal.

The stakes: updaters are the highest-value surface in an agent desktop app

Every desktop agent client has the same shape. A UI, a runtime that runs tools on your machine, and an updater that periodically fetches and installs new code with your permissions. The first two get the security attention. The third is the one that puts fresh binaries on your laptop on a timer.

For a note-taking app, a weak update path is bad. For an app whose entire purpose is running an agent that can spawn shells, it is the whole game. If you can influence what the updater installs, you do not need to find a bug in the agent. You are the agent.

My position on DSH Desktop is narrow and, I think, fair: the architecture is more careful than most projects at this size, the documentation is better than most projects at any size, and the update path has not caught up to the rest of it. The project agrees, listing "signed artifacts, Authenticode/publisher verification, SmartScreen reputation, and native upgrade testing" as items that "remain release gates."

What DSH Desktop actually is

DeepSeek Harness is DeepSeek AI's open-source agent harness, MIT licensed, built on the Cordis plugin kernel, where "everything is a plugin." It sits around 130.1k stars. Its own README says it is "currently in developer preview and is iterating rapidly. THERE WILL BE COMPATIBILITY-BREAKING CHANGES." You start the web UI with npx @deepseek-ai/dsh web and it serves at http://127.0.0.1:3080.

DSH Desktop is not from DeepSeek. It says so itself: "DSH Desktop is an independent community project, not affiliated with or endorsed by DeepSeek." Upstream returns the favor by not mentioning it. I read the full DeepSeek Harness README and there is no reference to DSH Desktop or to its publisher anywhere in it.

The publisher is anywhere-labs, a GitHub organization with the bio "Creating awesome AI APPs," a location of China, a website at dshdesktop.cn, three public repos, and no public members. Releases are published by an account named Bensonwang-owl, and the README contact is a QQ address. None of that is disqualifying. Plenty of good software ships from small teams with thin public profiles. It is context you should have before installing something that runs your login shell.

Architecturally the clever bit is that this is not a wrapper at all. The desktop shell registers as a DSH plugin, dsh-plugin-desktop, composing into the same Cordis runtime through the official plugin mechanism. Window, tray, terminal, updater, and profile switcher are plugins alongside everything else. For a project whose upstream slogan is "everything is a plugin," that is the respectful way to build it.

The fork that stopped being a fork

Here is a detail that changes how you read the README, offered as observation rather than accusation.

On the morning of August 14, GitHub served the repo page with "forked from deepseek-ai/deepseek-harness" at the top, the fork metadata set, upstream's exact file tree, and 12,314 commits of upstream history. By later the same day, the same repository ID had its own network root, a restructured tree built around dsh-plugin-desktop/, and no fork relationship.

The current README states: "DSH Desktop does not fork or modify upstream source." Today that is accurate. Upstream now lives as a pinned git submodule at deepseek-harness/ that "is not edited from Desktop branches," pinned to "the published DSH 0.1.0-rc.7 family and the corresponding official deepseek-harness/ release source."

Both statements are true at different times, and the README describes the present rather than the history. It matters only because a reader scanning the README for provenance gets today's answer and not last week's, and provenance is exactly what you are trying to establish when you decide whether to trust an installer.

The updater, in detail

This is the part worth knowing precisely, because the docs describe it precisely.

Sixty seconds after startup, and then every six hours, the app makes a no-cache request to https://www.dshdesktop.cn/api/desktop/version with a fifteen-second deadline. Background failures are silent. It accepts the response only if it parses as canonical stable SemVer. The version string on the other end comes from an Upstash Redis key that an operator sets by hand, documented right there in the README as SET deepseek-harness-desktop:release:version 2.0.1.

Nothing installs silently, and that is a design decision worth crediting. Clicking Download rechecks the version, hits a counted download endpoint, follows the redirect, and streams at most 1 GiB into a private versioned directory under user data. It rejects an incomplete DMG or a malformed Windows PE. On macOS it opens the DMG and you replace the app in /Applications yourself. On Windows it runs the NSIS installer after a second prompt.

Every one of those steps is a container check. Is this a real DMG, is this a real PE, is the byte count complete. None of them is a signature check.

The signing picture on the build side is split. The docs describe a signed and notarized macOS release path, yarn dist:mac run "on a credentialed macOS machine." They also describe a CI smoke build that "strips every Electron Builder macOS signing and notarization variable" and produces an artifact where "Gatekeeper will block it on other machines." On Windows, the local dist:win build "deliberately strips Windows certificate variables and sets signExecutable=false," producing something that "has no Authenticode publisher, so Windows can display an Unknown publisher or SmartScreen warning."

I could not verify whether the published release assets are actually signed. That is a gap in my reporting, not a finding, and I will not dress it up as one.

Credit where it is due: the rest of the architecture is careful

It would be unfair to dwell on the updater and skip what the project gets right, because it gets a lot right.

The renderer "uses contextIsolation, the Chromium sandbox, and no Node integration." There is "no Electron-owned plugin roster, preload bridge, or raw Electron API in the renderer." The host binds HTTP and WebSocket to 127.0.0.1 on an ephemeral port and Electron loads that same-origin page, with navigation and redirects held to "the exact loopback origin" while external links open in the OS browser. That is the shape you want.

The environment handling is better than I expected. On packaged macOS and Linux launch, the app runs your account shell in interactive login mode to recover PATH, the usual fix for the "works in terminal, broken in the GUI app" problem. What is unusual is the filtering. Capture starts from upstream's scrubbedParentEnv(), names have to pass a sensitive-pattern check, and the result is that "credentials, DSH_* values, proxy and SSH-agent settings, and process startup hooks learned only from shell rc files are therefore not imported into Electron." Somebody thought about that.

On Windows it keeps upstream's pwsh-sandbox and ACL confinement in both modes, with "no automatic unrestricted fallback when Windows confinement fails." Upstream's danger-full-access PowerShell mode still exists and is unchanged, so the dangerous thing stays available and stays honestly named.

Put this into practice

Try upstream first. You do not need the desktop client to evaluate DeepSeek Harness. npx @deepseek-ai/dsh web gets you the web UI on 127.0.0.1:3080 with no third-party packaging in the trust path at all. Decide whether you like the harness before you decide whether you like the wrapper.
If you install Desktop, take it from GitHub Releases, not the .cn download endpoint, and check the published SHA-256 digests against what you downloaded. The docs say installers and digests are on Releases; the primary download links point elsewhere.
Check the signature yourself before you trust the auto-updater. On macOS: codesign -dv --verbose=4 "/Applications/DSH Desktop.app" and spctl -a -vv "/Applications/DSH Desktop.app". On Windows, right-click the installer, Properties, Digital Signatures. No publisher identity there means the six-hour update loop is fetching unsigned code from one endpoint, and that is a call to make deliberately rather than discover later.
Read dsh-plugin-desktop/README.md before filing an issue. The Known Limitations section is long, specific, and answers most of what you are about to ask. Profile changes need a restart. Advanced mode does not exist on Linux. dshmarket@1.2.3 is "an optional user-installed third-party package, not a bundled marketplace."
Know where the logs are before you need them. ~/Library/Application Support/DSH Desktop/logs on macOS, %APPDATA%\DSH Desktop\logs on Windows, rotating at 10 MiB with 7-day retention. The diagnostics ZIP masks recognized credentials, but the docs warn it "can still contain local paths, workspace IDs, session IDs, prompts, tool output, or third-party plugin messages." Read one before you attach it to a public issue.
Pin your expectations to 0.1.0-rc.7. That is the DSH family this ships against, and upstream is a developer preview promising breaking changes. Do not build a team workflow on this pairing yet.

Honest limitations

The publisher-identity gap in the updater is the one to weigh, and it applies on both platforms. Windows Authenticode is an open item by the project's own account.

The star numbers are unstable and I am not going to pretend otherwise. GitHub served me 225 stars on August 14, then 581, then 7,090 on August 16, then 9.9k, then 11.6k with 517 forks, 122 open issues, and 53 open PRs at the freshest read on August 17. That is a growth curve rather than a contradiction, but any figure quoted about this repo is a timestamped snapshot, mine included.

The release picture is muddled. One tagged release, v0.1.0, published August 13, while the packaging docs reference an artifact named DSH-Desktop-2.0.1-x64-Setup.exe, so a 2.x line exists that I could not enumerate. Two docs also disagree on macOS architecture support: the top-level README says Apple Silicon only with Intel "planned," while the packaging doc describes a universal DMG verified on both slices.

Credential storage is undocumented. No Keychain integration described, no electron-store mention, no on-disk path for API keys. Secrets live in upstream's DSH home in settings.yaml. If you want to know exactly how your key is protected at rest, the answer is that nobody has written it down.

The Electron security posture I described comes from the project's architecture documentation, not from reading main.ts. Treat that section as claims. Well-made claims, but claims. I also could not reach the repo's security advisories, so I cannot tell you whether anything security-labeled is open. Open issues went from 73 to 122 in three days, which is what 11,000 stars in four days does to a small team.

What to take from this

The best signal here is not any single feature. It is that a repo growing several thousand stars a day wrote down, in its own Known Limitations, the exact sentence a security reviewer would have written about it. Most projects at that growth rate are writing marketing copy instead.

Go read that section before you install anything. Then read the equivalent section in whatever agent desktop app you are already running, and notice whether it has one.

Sources: anywhere-labs/deepseek-harness-desktop (repo README, dsh-plugin-desktop/README.md, docs/architecture.en.md, docs/faq.en.md, releases page); deepseek-ai/deepseek-harness; cordiverse/cordis; anywhere-labs organization page. All repository counts are GitHub-served HTML snapshots dated in-text.