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

The gap this fills: plugin discovery is the hard part, not installation

DeepSeek Harness is a web workspace. Studio wraps it in Electron and adds a layer that the README describes as zero-code desktop enhancement: plugin discovery, push of newly updated plugins, one-click install and management, AI recommendation, and vision routing. The target user is someone who wants the Harness agent workspace without touching a terminal to find, vet and install plugins. That is a narrower claim than it first appears. The README is explicit that `dsh-plugin` is only a discovery signal and that GitHub is used solely to map already-published npm packages; Studio does not install repository source. So the product is a curated index plus a lifecycle manager, not a package builder. If you are comfortable running `npm install` against a known package name and editing a config, most of the plugin value here is convenience, not capability. The discovery side is where the project actually differs, because the README states the app reads an online catalog and organizes it into featured, recently updated and ecosystem-popular views, with scenario filters covering agent and workflow, web UI, browser and search, vision and media, memory and context, model and service, developer tools, and integration and notification.

How the desktop shell and the local dsh web service fit together

The architecture is stated plainly: Electron hosts the DeepSeek Harness web workspace, and the desktop main process starts and manages a local `dsh web` service. The README notes the host runs with `--no-open`, which keeps the service from launching a browser window of its own, and that the app preserves native directory selection, plugin transaction recovery and the existing user data directory. Sessions are grouped by Workspace, and the README says a Workspace is opened through a native directory picker. Long conversations get a right-side table of contents covering the full history while the body still loads page by page; summaries are capped at 80 characters, and clicking an unloaded entry triggers continuous paging, then collapses the panel and highlights the full message. Plan, Goal and Todo organize the current task. The Jobs panel shows background tasks inside the current process, and the README is careful to say that after a process restart those running tasks are not treated as still alive. SubAgent sessions expose parent-child lineage, status and elapsed time. Permissions are fixed per session through presets that combine a sandbox mode with an approval policy, and credentials are saved through a write-only interface so the page never reads back stored secret values.

Getting it running: clone, install, start, or take a release build

There are two paths and the README keeps them separate. The first is the source route: clone the repository, install dependencies locally, edit source, and start the desktop app. The README does not print the exact npm script names, so the precise command to launch the Electron shell is not confirmable from the supplied material; the repository layout is a monorepo with an `apps/web` directory and a desktop composition, which is consistent with a workspace-based install, but that is an inference, not a quoted instruction. The second path is the release build. The README links a macOS arm64 preview ZIP and a Windows x64 preview installer for `desktop-preview-v0.1.0-rc.19`, and states that desktop installers are published only through this repository's GitHub Releases, not through third-party download sites. On the configuration side, the README names the local inference endpoints the app can connect to from a first-level entry: Ollama, vLLM, SGLang and a custom OpenAI-compatible service. It also describes a vision path where `DeepSeek-V4-Flash-Vision-Exp` handles images directly, with persistent image attachments and Files API image reuse; when a reference goes stale the request is retried within bounds, and if parsing fails the whole request falls back to restricted inline images. Those are the concrete knobs the material supports. Anything beyond that, such as environment variable names or a settings file schema, is not in the README.

Plugin install is a transaction, and the failure path is the interesting part

The plugin center 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. Before install, the README says the app checks a definite version, permissions, compatibility and risk. After install, enable, disable, update and uninstall are handled in the same place. The part worth reading twice is the recovery behaviour: an unfinished transaction rolls back automatically, and if the runtime manifest still does not match, the app enters a plugin safe mode where plugins can be disabled or uninstalled. There is also a compatibility case for historical plugin lock files: when a lock file is incompatible, the README states the app enters a recovery path that does not rewrite the lock file. That is a deliberate choice to avoid destroying state you might need, and it also means the app may run in a reduced mode rather than repairing itself. The natural-language finder works differently from the install path. Typing a description such as wanting a desktop pet plugin is sent as a `/find-plugins` request to the current agent, which loads a built-in skill, queries the public `dsh-plugin` catalog read-only, and returns candidates with version, author, update time and per-item match reasons. The README separates the two steps on purpose: recommendations are catalog metadata only, and installation still goes through the plugin center for compatibility checks and confirmation.

Where it is the wrong tool, and what the README leaves out

The release channel is the first constraint. The current line is `desktop-preview-v0.1.0-rc.19`, tagged as a preview, and the only published artifacts are macOS arm64 and Windows x64. There is no Linux build in the material, and no statement that one is planned. If your team runs Linux workstations, this is not a candidate today. The second constraint is the version split. The README says Studio `0.1.0-rc.19` integrates DeepSeek Harness `0.1.1-rc.2` core and web capabilities, and that Studio and upstream Harness version numbers are managed separately. Two independent version streams on a preview cadence means upgrade testing is your problem, and the material gives no compatibility matrix beyond the current pairing. Third, the roadmap table is honest about what is missing: a standalone capability center for MCP servers, Skills and tools outside Bundle packaging; a visual agent orchestration editor; and remote control with browser or desktop automation and mobile handoff. Those are listed as directions, not features, and the README explicitly says they are not counted in the current feature set. Finally, the README does not document an update mechanism for the desktop app itself, nor does it state what data leaves the machine when the plugin catalog is queried. If either matters to your review process, that is an open question you cannot answer from this repository's documentation.

The alternative: run the Harness workspace in a browser without the Electron layer

The most direct comparison is the upstream DeepSeek Harness web workspace itself, which is what Studio embeds. The difference in approach is where the plugin work happens. Upstream, you find a package, install it with your package manager, and manage enablement and versioning through your own lockfile and scripts. Studio replaces that with a catalog-driven GUI: discovery views, scenario filters, agent-assisted search, pre-install compatibility checks, and a transaction model with rollback and safe mode. The trade is control for convenience. A lockfile you wrote is auditable, diffable and reproducible in CI; a plugin installed through a desktop GUI is managed by the app's own manifest and transaction logic, and the README's recovery path for incompatible lock files suggests that state can drift from what a plain npm workflow would produce. If you need plugins pinned in CI, or if the same plugin set must be reproduced across machines, the manual path is still the better fit. Studio's advantage is concentrated in the discovery step, where you do not know the package name and the catalog plus the `/find-plugins` agent can narrow it down. For a single developer on macOS or Windows who wants to browse and try plugins quickly, the GUI is the shorter route.

Maintenance cost, licence, and what to check before you commit

The project is MIT-licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That is a statement about the licence text, not legal advice; if you redistribute a modified build, read the LICENSE file in the repository rather than relying on this summary. Maintenance cost comes from three places. The first is the preview cadence: three releases are visible in the material, `rc.17` on 2026-08-24, `rc.18` later the same day, and `rc.19` on 2026-08-25, which is a fast iteration rate and implies frequent rebuilds if you track it. The second is the dual version stream, since Studio and Harness move independently and the README only documents one pairing. The third is the plugin transaction model: rollback and safe mode are safety features, but they also mean a failed install can leave you in a reduced state that you have to resolve in the app rather than by editing a file. Before adopting, check three things against the actual release you download: that the asset name matches the `rc.19` tag, that the app reuses the user data directory you expect rather than creating a new one, and whether your existing plugin lock files are in the compatible format, since the README states incompatible ones trigger a recovery path that leaves the lock file untouched.

Editorial conclusion

Adopt it if you already run DeepSeek Harness and want plugin discovery, install and rollback handled in a GUI on macOS arm64 or Windows x64, and you accept preview-quality builds. Do not adopt it if you need Linux, a stable release channel, or if you would rather keep plugin installation in your own npm and lockfile workflow. Before installing, verify that the release asset you download matches the rc.19 tag, that your existing plugin lockfile is compatible (the README states incompatible locks trigger a recovery path that does not rewrite the lock file), and that the workspace data directory it reuses is the one you expect.

Official sources

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