DeepSeek Harness Studio: an Electron shell for the DSH plugin ecosystem

What DeepSeek Harness Studio adds to the harness

DeepSeek Harness is a terminal-oriented agent workspace. Studio is the zero-code desktop layer on top of it: an Electron application that hosts the harness web workspace and whose main process starts and manages a local `dsh web` service. The repository describes the product as the "zero-code desktop enhancement" for DeepSeek Harness, and the feature table lists desktop workspace and session management, a long-conversation table of contents, plugin discovery, a Preset square, an application centre, multi-model and local inference configuration, Plan and Goal and Todo and Jobs views, SubAgent collaboration, permission and sandbox controls, and theme skins.

The audience is narrow but real. If you already run DeepSeek Harness and you keep installing plugins by hand, or you want Ollama, vLLM or SGLang wired into the same interface as a hosted model, Studio is aimed at you. If you only want to talk to a model, the desktop shell is overhead you do not need. The repository is public under MIT and the last push was on 2026-09-01, so it is not archived and it is not stale.

How the Electron host and the dsh web service fit together

The architecture is two processes plus a workspace. Electron carries the web workspace; the desktop main process starts and manages the local `dsh web` service; the README notes that the host runs with `--no-open`, which keeps the service from opening its own browser window because the Electron shell is already the window. Native directory selection, plugin transaction recovery and the existing user data directory are preserved across that boundary.

Plugin discovery is a separate data path from plugin installation, and the README is explicit about the split. Discovery reads an online directory and surfaces curated, recently updated and popular entries. The Agent path is different: a natural-language request becomes a `/find-plugins` request, the Agent loads a built-in skill, queries the public `dsh-plugin` directory read-only, and returns candidates with versions, authors, update times and per-item match reasons. Installation is a third step. The plugin centre accepts a short package name, a full npm package name or an explicit GitHub repository, and resolves it to a plugin or Skill Pack published to the public npm registry. The README states that `dsh-plugin` is only a discovery signal and that GitHub is used only to map an already published npm package, because Studio does not install repository source directly. A determined version still has to pass Bundle, integrity and runtime compatibility checks.

That three-stage separation is the most interesting design decision in the repository. It means a recommendation is metadata, not a decision, and the install path is where verification actually happens.

Installing the preview and running a first Agent search

The desktop installers are published only through this repository's GitHub Releases, and the README says third-party download sites are not used. The 0.1.0-rc.19 release provides a macOS arm64 preview ZIP and a Windows x64 preview installer. There is no documented Intel Mac build and no Linux package in the release list, so on those platforms you are building from source rather than installing a binary.

The source route uses pnpm at the version pinned in the root package.json and a Node engine range of `^22.19.0 || >=24.0.0`. From a clone, the install and desktop start look like this:

corepack enable
pnpm install
pnpm run build:desktop

The README does not document a separate `pnpm dev` desktop command, so treat the build script as the entry point and check the contributing guide in the repository for the development workflow it actually supports.

Once the app is open, the first real use is the Agent plugin search. Open 插件发现 (plugin discovery) from the left, describe what you want in plain language, and the request goes to the current Agent as `/find-plugins`. The README's own example asks for a desktop pet plugin; the Agent loads the `find-plugins` skill, searches the public directory, and returns five candidates out of eight results with package names, versions, publishers, update times and match reasons. Selecting a package name moves you to the plugin centre, where the compatibility check and the confirmation happen before anything is installed.

The plugin trust boundary, and where it can still bite

Studio's own documentation draws a line it does not cross: it will not install a GitHub repository's source. That removes an entire class of supply-chain surprises, and it also means a plugin that is not published to npm is invisible to the installer no matter how good it is. If your team's internal plugins live in a private registry or a git URL, the plugin centre is the wrong tool for them.

The lifecycle machinery is more careful than the marketing implies. The README describes pre-install checks for a determined version, permissions, compatibility and risk; unified enable, disable, update and uninstall afterwards; automatic rollback of unfinished transactions; and a plugin safe mode that still allows disable and uninstall when the runtime manifest remains inconsistent. That last path is the honest admission that an install can end in a state the app cannot fully reconcile. The README also notes that an incompatible historical plugin lock file triggers a compatibility recovery that does not rewrite the lock file. What the README does not document is a manual rollback procedure for a plugin that installed cleanly and then misbehaves at runtime, so plan on uninstall as your recovery.

A second limitation is packaging. The releases are labelled preview and the version is 0.1.0-rc.19, with rc.17 and rc.18 shipped in the same week of August 2026. Preview cadence means interfaces and install behaviour can move between builds. If you need a frozen version for a team, this is not it yet.

DeepSeek Harness Studio versus the plain CLI harness

The alternative is the upstream DeepSeek Harness itself, run from the terminal. Studio `0.1.0-rc.19` states that it integrates DeepSeek Harness `0.1.1-rc.2` core and web capabilities while keeping the plugin centre, plugin discovery, Preset square, application centre, theme skins and desktop recovery paths. The two version numbers are managed separately, which is worth understanding before you file a bug: a Studio release and a Harness release are different artifacts.

The practical difference is what each one optimises for. The CLI harness gives you the agent loop and the plugin system with no Electron layer, no desktop installers and no GUI verification of plugin permissions. Studio adds the graphical plugin lifecycle, the Preset square with its seven built-in workflows, the application centre and the local model entry points for Ollama, vLLM and SGLang. If your workflow is scripted or headless, the CLI is the better fit and Studio's plugin centre is a detour. If your workflow involves handing the harness to someone who will not open a terminal, Studio is the whole point. The repository's own roadmap is candid that a standalone capability centre for MCP servers, Skills and tools, visual agent orchestration, and remote control are not first-class product entries yet.

Licence and the cost of tracking release candidates

The repository is MIT licensed and the root package.json carries the same identifier, with a THIRD_PARTY_NOTICES.md at the top level for bundled dependencies. MIT is permissive, so redistribution and modification are permitted under its terms; if you ship a modified build, keep the notice file and the copyright statement intact. Nothing here is legal advice, and the notices file is the document to read if you plan to redistribute.

Upgrade cost is the real maintenance question. The release history shows desktop-preview-v0.1.0-rc.17, rc.18 and rc.19 all published within about 24 hours of each other in August 2026, which tells you the preview channel moves quickly and that pinning a single RC is the only way to get a stable target. Studio also has to track Harness upstream separately, so an upgrade can involve two version numbers and a plugin lock file compatibility check. Budget for reading release notes before every bump rather than assuming an in-place update is safe.

Editorial conclusion

Adopt DeepSeek Harness Studio if you want the DeepSeek Harness workspace on Windows or macOS, you are comfortable running a release candidate, and the plugin centre is the reason you are here rather than the chat UI. Do not adopt it if you need a stable version number, an Intel Mac build, Linux packaging, or a plugin source you compile yourself, because the repository states that Studio maps to published npm packages and does not install repository source. Before installing anything, check the release page for a build newer than desktop-preview-v0.1.0-rc.19, read PLUGIN_CENTER_USAGE.md for the exact verification sequence, and confirm whether your DeepSeek Harness plugin lock file is compatible, since an incompatible lock file triggers the compatibility recovery path.

Frequently asked questions

Official sources

1. fufankeji/deepseek-harness-studio on GitHub
2. License: MIT
3. Project website
4. README
5. Releases