DeepSeek Harness: the open-source agent runtime where everything is a plugin

What it is

DeepSeek Harness (CLI name dsh) is the open-source agent harness from DeepSeek AI. Its self-description is a single line: everything is a plugin. It is not a bundle of built-in capabilities but a host: nothing outside the kernel is hard-coded, and tools, surfaces, model access, and commands all attach to one runtime as plugins. The project is MIT-licensed, has more than 233,000 GitHub stars, and is currently in developer preview. The README warns in capitals that there will be compatibility-breaking changes, and asks you to read SAFETY.md before running it.

Installation is one command: npx @deepseek-ai/dsh web. It starts the Web UI at http://127.0.0.1:3080 by default and opens it in the default browser for a local launch; an SSH launch only prints the host URL, because the SSH client or editor owns the forwarded address. Pass --no-open to serve without opening a browser. Running from source is git clone, then pnpm install, pnpm run build, pnpm dsh web: build prepares the repository artifacts, and the subsequent pnpm dsh web reuses them without rebuilding.

Why "everything is a plugin" is an architecture choice

In agent work, harness means the runtime wrapped around the model: who owns the session, who dispatches tool calls, who manages context, who decides interrupts and resumption. Most harnesses ship a set of built-in capabilities (filesystem, shell, search, browser) and then expose configuration flags to toggle them. DeepSeek Harness inverts this: the kernel provides only the semantics of a plugin system, and capabilities come from plugins.

The technical foundation is Cordis. The project says it is powered by Cordis and puts the design in a paper: A Programming Paradigm for Spatiotemporal Composability (arXiv:2608.25512). Two words in that title carry the argument. Composability means plugins can depend on one another and supply context to one another. Spatiotemporal means that composition has to hold along both axes: in time, plugin lifecycles and the ordering of asynchronous events must remain reason-about-able; in space, plugin scopes must nest, isolate, and share. Making both first-class is what lets the kernel be empty enough to contain nothing but the plugin system.

Two practical consequences follow. First, the capability boundary is set by what exists in the ecosystem rather than by what the vendor bundled: the project defines a dsh-plugin GitHub topic so plugin authors can tag their repos for discoverability. Second, replacement is cheap. If you dislike a default implementation you write a plugin against the same interface and shadow it, rather than forking the kernel.

Developer surface and documentation layout

The documentation site is deployed separately at deepseek-harness.github.io, and the repo splits docs into user and developer sides: docs/user/guide/index.md for the Web UI guide, docs/development.md for the development guide, docs/architecture.md for architecture. That split is itself an expression of everything-is-a-plugin: users never need to know the plugin system exists, developers do.

Local development has one command that folds three steps into a single terminal: pnpm run dev:web builds, serves, and rebuilds client bundles on source edits. make help lists the matching Make targets for Web and Desktop, and the full command table lives in the development guide's application commands section rather than being scattered through the README, which is a restrained choice. The repo also ships an AGENTS.md, the rules file written for agents. A harness project carrying its own agent spec tells you that agents are first-class participants in how it is developed.

Boundaries, and what you have to judge yourself

Three things need stating plainly, or readers will over-rate it. First, developer preview is not marketing language: the README states THERE WILL BE COMPATIBILITY-BREAKING CHANGES in capitals and asks you to read SAFETY.md before running the project. Elevating a safety notice to "read before running" implies the harness holds substantial execution privilege by default. It can run commands and touch files, and the plugin model lets third-party code into that same runtime.

Second, the plugin ecosystem is simultaneously its strength and its risk surface. The smaller the kernel, the more capability depends on third-party plugins, whose quality, maintenance status, and supply-chain safety are outside the vendor's control. The only discoverability mechanism the README describes is a topic tag; there is no account of a curated or reviewed plugin marketplace.

Third, we have not benchmarked or reproduced it. Star counts measure attention, not capability. It belongs at the top of the harness ladder because it is an unavoidable architectural specimen on that spine - a minimal kernel with everything else carried by plugins - not because we measured it beating anything. We grade this entry as needing reproduction.