DeepSeek Harness Desktop App: What the Installer Actually Puts on Your Machine

The DeepSeek Harness desktop app is an Electron shell wrapped around the same web interface you get from npx @deepseek-ai/dsh web, and it ships as three platform-specific installers for a harness that currently stands at version 0.2.1-rc.2. That description sounds dismissive and is not meant to be. Wrapping a working interface in a desktop container is a weekend of work; wrapping it in a container that owns its own runtime directory, keeps your tasks alive when you close the window, updates itself on a channel with no stable release, and preserves your sessions across every one of those operations is the part that takes months, and it is the part worth reading about. If you want to run DeepSeek-V4.1-Flash through a harness that lives in a window rather than a terminal, this is that build, and the interesting questions are all about what happens around the window.

Two things need saying before the details. First, this article supersedes our earlier guidance that there was no desktop app — that guidance was correct when it was written in August 2026, and it is wrong now. Second, this is a public preview, still labelled as such on DeepSeek's own site, and the packaging has the rough edges that label implies. The installer works. The distribution around it is thinner than you would guess.

What the desktop build actually is

The desktop application is a thin Electron layer whose job is to start a Host process and point a window at it. The window does not lay out a chat interface of its own: it loads the packaged Web entry bundled inside the app at dsh-app://app/, and the update dialogs you will see come from a second bundled origin at dsh-app://shell/. A child Node process is launched in Electron's RunAsNode mode to start the shared profile runner, and the shell forwards HTTP to the authenticated Web Host, dropping the transfer-encoding, connection and keep-alive headers on the way through. Plugin bundle responses are marked no-store, which is a small detail with a visible consequence: change a plugin and the next reload shows the change.

Because the URL is dsh-app:// rather than localhost, there is no fixed port to remember and no port collision to work around. The desktop Host listens on an OS-assigned port by default. If you need a specific one you can set it through a webserver.config.port override, but the default is deliberately not a constant, and the Host binds 127.0.0.1. This matters if you have been following older instructions: the number 19387 that circulated in August install guides is not the desktop port, and treating it as one will send you looking for a service that is not there.

The version pinning is stricter than it first looks. Electron and @deepseek-ai/dsh always carry exactly the same version — not a range, not a compatible major — so an upgrade to the harness is a desktop release, and there is no supported combination of a new dsh and an old window. The Electron process takes a process-lifetime single-instance lock and exclusively owns $DSH_HOME/profiles/desktop. That exclusivity is real: the CLI cannot boot that profile, and an npm-installed dsh cannot mutate it. What the two installations do share is the state that matters to you — sessions, settings, credentials, workspaces and storage, all under $DSH_HOME. What they do not share is executable packages, plugin activation, lockfiles or node_modules, which is why installing a plugin into the desktop profile is not the same operation as installing one into the CLI profile.

Three installers, one update channel, no stable release

Three installers exist and all three respond. The Windows 64-bit executable is 289,385,456 bytes and served with HTTP 200. The Apple-silicon disk image is 264,990,950 bytes, also 200. The Intel Mac disk image is 289,480,824 bytes, also 200. All three were last modified on 17 October 2026. Only two of them are linked from the download page. The Intel build is live, is reachable, and has no link pointing at it anywhere on deepseek.com/en/harness/ — if you are on an Intel Mac and you followed the page, you would reasonably conclude there was no build for you.

The Intel build is also a version behind. Its update feed lists 0.2.1-rc.1; the Windows and Apple-silicon feeds both list 0.2.1-rc.2. One release candidate is not a large gap in features, but it is a real signal about which targets get built first and which get verified last, and it is exactly the kind of thing you want to know before you commit your working sessions to a platform.

The update channels are where the distribution story gets thin. The feeds are per target, under /dsh-desk/feeds/<target>/ on the same host. Windows x64 resolves nightly.yml; both macOS targets resolve nightly-mac.yml. Ask any of the three for latest.yml or latest-mac.yml and you get a 404 — there is no stable channel, no beta channel, and no way to opt out of the one that exists. DeepSeek's own publishing notes confirm the arrangement rather than contradicting it: every release publishes a nightly feed, and only stable releases publish a latest feed pointing at the same artefacts. "Nightly" in this context is a channel name rather than a build cadence — the Windows and Apple-silicon feeds both serve the same 0.2.1-rc.2 build, dated 17 October, with the Windows package timestamped 09:22 UTC and the Apple-silicon package 09:57 UTC. So you get the automatic-updater machinery, jittered polling, backoff to a one-hour cap, and no way to ask for anything other than what the preview channel currently holds.

GitHub makes the same point from a different angle. The deepseek-ai/deepseek-harness repository — 256,559 stars and 30,921 forks when it was read on 21 October 2026 — had 31 releases on the same date, every one of them flagged as a prerelease, and every one of them with zero binary assets attached. Nothing on the Releases page is downloadable. If you want a build, you get it from download.deepseek.com or from npm, where @deepseek-ai/dsh currently resolves latest to 0.2.1-rc.2. The repository is a source of truth for the changelog and a dead end for the artefact, which is unusual enough to be worth stating plainly, because the instinct on seeing 31 releases is to expect an installer on one of them.

What the installer writes, and what it refuses to touch

The Windows installer is a native NSIS package, not a wrapper around an MSI, and it behaves like one. You get light, dark and auto palettes — selectable at install time with /THEME=light, /THEME=dark or /THEME=auto — an editable destination directory, and an install scope limited to the current user. Drive roots are rejected as destinations, and a non-empty destination is accepted only if it is already a registered installation, which is the installer refusing to overwrite an unrelated folder. On update, the silent path waits up to ten seconds for the running application to exit and then stops with exit code 2 if it is still running. That is an honest failure rather than a corrupted install, and it will show up in any scripted deployment that does not quit the app first.

The uninstaller draws the line that most uninstallers get wrong. It removes the Electron userData directory, the product directory under %APPDATA%, and the updater cache under %LOCALAPPDATA%. It does not touch the harness home — ~/.dsh, or wherever DSH_HOME points — which holds your sessions, settings, credentials and plugins. Passing --updated or /KEEP_APP_DATA retains the Electron data as well. So uninstalling and reinstalling is a supported way to fix a broken window without losing your work, and that is a deliberate design decision rather than an accident.

The bundled runtimes are worth knowing about because they are large and they live outside the app directory. Python with numpy, pandas, python-docx, python-pptx, openpyxl, Pillow, lxml and XlsxWriter, plus Node and pnpm, are installed under $DSH_HOME/dsh-runtimes/dsh-primary-runtime — normally ~/.dsh/... on both platforms — the first time a workspace declares it needs them. That is why the disk footprint after a week of use is not the disk footprint after installation, and why an uninstall that preserves $DSH_HOME also preserves several hundred megabytes of runtimes.

Settings are read once at startup from desktop/settings.json inside the Electron userData directory, which on Windows means %APPDATA%\@deepseek-ai\dsh-desktop\desktop\settings.json and on macOS means ~/Library/Application Support/@deepseek-ai/dsh-desktop/desktop/settings.json. DSH_HOME does not relocate this file — a point worth flagging, because it is the one piece of configuration that does not follow the variable everything else follows. The update settings in that file are milliseconds: intervalMs defaults to 600,000, and maxBackoffMs defaults to 3,600,000 and must be at least intervalMs. Jitter defaults to 0.2, is clamped to a range of zero to one, and is floored at one second while never exceeding the backoff cap. A per-connection inactivity deadline of 60,000 milliseconds applies to update HTTP traffic, though an active download has no total-duration deadline — a slow link will not be cut off mid-download.

Closing the window does not close the application

On both platforms, closing the window hides it. On macOS that is Command-W; on Windows it is the close button, Alt-F4, or Close from the taskbar. Windows asks for acknowledgement before the first hide and writes a background-close-confirmed flag under the Electron userData directory so it asks once and not every time. Windows also keeps a tray icon for the entire run. macOS ships no menu-bar icon at all, which makes the hidden state genuinely invisible there — the app is running, tasks are running, and nothing on screen says so until you reopen it with dsh://open or the tray, depending on platform.

What survives the hide is the useful part. Running tasks keep running, and the next time the window is shown it presents the same document with the same session, the same drafts and the same scroll position. This is a different behaviour from a browser tab that you close and reopen, and it is the reason the desktop build is worth having at all if your work involves long-running agent tasks: you can close the window and let the task finish.

Quitting is a separate action with its own logic. Before quitting, the shell inspects the Host for running agents including subagents and agents waiting on approval, queued messages, jobs that are running or stopping, and scheduled reminders that are armed. If none of those exist, it quits silently. If any do, you get a native confirmation dialog titled Quit DeepSeek Harness? with one of three explanations depending on what it found: tasks will be interrupted, scheduled tasks will not run, or both. A Host that never reached ready cannot have started any tasks, so quitting in that state proceeds without asking. The distinction between "close" and "quit" is the whole point of the design, and it holds on both platforms even though only one of them shows you a persistent icon.

The dsh command, and the order that matters

The installer can put dsh on your PATH, which is what lets you run the CLI against the same harness home the desktop app uses. The control is Manage dsh Command…, and it sits immediately below Check for Updates… in the menu, with three actions: Install, Repair and Remove. On macOS it writes a launcher at /usr/local/bin/dsh and will prompt for administrator authorisation when it needs it; on Windows it registers the command in the current user's PATH.

Two sequencing rules are easy to miss and annoying to discover afterwards. The first: run Remove before uninstalling the desktop application, because the uninstaller does not remove the dsh registration. Uninstall first and you are left with a PATH entry pointing at a binary that no longer exists. The second: if you move the application to a different location, use Repair on macOS or Install from the new location on Windows, rather than assuming the registration follows the app.

Plugin management for the desktop profile has its own wrinkle. Because Electron exclusively owns $DSH_HOME/profiles/desktop while it runs, installing into that profile is not something you do with the app open. The supported sequence is to launch the desktop app once, quit it, and then run dsh plugin --profile desktop add <package> from the command line. The package lands in the desktop profile and is active the next time you open the window.

What the packaging already tells you is unfinished

The README's known-limitations section is unusually candid, and two of its entries are the ones that will affect you first.

• Account sign-in is not connected. The Sign in button is disabled. Instead, the first run opens a 600 by 700 welcome window with an API-key form; Save and continue writes the key to the development credential store, and Set up later opens the real workspace without saving one. Pressing Sign in where it appears opens the configured platform page in your system browser, with the Host owning the PKCE exchange and a temporary loopback callback — the plumbing exists, the account binding does not. In practice, plan on bringing a key.

• Release signing and notarisation are listed as requiring the production release environment. That is the README being careful, and it is also where a measurement is more useful than a sentence. The published Windows executable carries a valid Authenticode signature with an extended-validation chain: GlobalSign Root CA–R3, down through the GlobalSign Code Signing Root R45 and the GlobalSign GCC R45 EV CodeSigning CA 2020, to a leaf certificate issued to Hangzhou DeepSeek Artificial Intelligence Co., Ltd. with jurisdiction listed as CN / Zhejiang / Hangzhou, and a private-organisation business category. The RFC-3161 timestamp on that signature reads 2026-10-17T09:22:04Z, which matches the release date in the Windows update feed to within a minute, and the SHA-512 digest of the downloaded file matches the hash published in that feed byte for byte. So on Windows the binary is signed, timestamped and hash-matched today, whatever the README says about the process not being fully productionised. The macOS side is a different question and we did not verify notarisation there; do not read the Windows result across.

Crash reports, and one detail worth knowing

Crash reports are written as crash-<UTC time>-<source>.log, into ~/Library/Logs/DeepSeek Harness on macOS or a logs directory under the Electron userData path on Windows, and the ten most recent are kept. That retention count is small enough to matter: if something goes wrong repeatedly and you do not look for a few days, the log that would have explained the first failure is gone. Copy the directory if you are debugging something intermittent.

The recovery path for a corrupted configuration is equally specific. The shell renames cordis.patch.yml to cordis.patch.yml.bak-<timestamp> without parsing it, so the file is preserved rather than repaired, and the app starts from defaults. If you have hand-edited that file, the .bak is where your edits went, and it is still readable.

Where this leaves the earlier "no desktop app" advice

We published guidance in August 2026 that the harness had no desktop application and that Windows users should run the terminal build — that was accurate at the time and it is now out of date. The terminal build still works and is still the right choice for a server, a container or anything scripted. What has changed is that the desktop build is not a toy wrapper: it owns a separate profile, keeps tasks alive through a window close, updates itself, and shares state with the CLI in the direction that helps you. If you were putting off the desktop build because the earlier article said it did not exist, that reason is gone.

The installation steps themselves are covered in our install walkthrough and are not repeated here, deliberately. What that walkthrough cannot tell you is which of the three installers has no link on the download page, which target is a release behind, that there is no stable update channel to opt into, and that the Windows binary is signed even though the README says signing belongs to a future release. Those are the facts that decide whether the desktop build is the right thing to install, and they are the reason this page exists separately.

If you would rather not install anything

Installing a harness to reach one model is a lot of surface area for a small amount of work, and the desktop app is a preview with a single update channel and an Intel build nobody links to. If what you actually want is DeepSeek-V4.1-Flash — the model the harness defaults to, the same one the 0.2.1-rc.2 notes add support for — an API endpoint does that with no installer, no profile directory and no tray icon that you have to remember is running.

The comparison to make is not desktop app against API in the abstract. It is whether the work wants an agent that can hold a workspace open across a closed window, run scripts on your machine and keep a session alive for hours — in which case the packaging problems above are worth putting up with, and the desktop build is the only way to get that behaviour — or whether the work is a stream of requests to a model that is already served somewhere else. For the second case, the model directory is the shorter path, and there is nothing in this article that changes it.