DeepSeek Harness on GitHub: Node Version Check + Plugin Config Generator

DeepSeek Harness is DeepSeek's own agent framework, published as a developer preview on GitHub under the MIT license. The project's stated organizing idea is "everything is a plugin": the inference adapter, the tool registry, session persistence, the agent control loop and the web interface are each separately swappable pieces, rather than one integrated binary the way a coding-agent CLI usually ships. That plugin-first design is the reason the config generator above exists at all - there is no single settings screen, only a list of plugin entries you assemble yourself.

Getting it running does not require cloning the repository. The documented quick path is npx @deepseek-ai/dsh web, which starts the bundled web UI on port 3080. Building from source instead means cloning the repo, then pnpm install and pnpm run build before pnpm dsh web - the path people take when they plan to write their own plugin rather than just use the ones DeepSeek ships.

Source: deepseek-ai/deepseek-harness README and install instructions.

The repository's package.json declares engines.node as ^22.19.0 || >=24.0.0. Read literally, that means the 22.x line only counts from patch 22.19.0 onward, all of Node 23 is outside the range since 23 was never an LTS release, and 24.0.0 and everything after it is fine. A perfectly normal looking "Node 22" install can still fail this check if it is an early 22.x build from before the floor was raised.

The checker above parses whatever version string you enter and tests it against both ranges, rather than assuming a single cutoff. Package managers enforce engines inconsistently - npm only warns by default, while pnpm can be configured to fail the install outright - so a Node version outside this range does not always stop you at install time.

Source: the engines.node range shown in the repository's package.json, cross-checked against the install guide referenced in the deepseek-ai/deepseek-harness repo.

Cordis is the dependency-injection framework DeepSeek Harness is built on. Every capability - tools, the LLM adapter, file access, even the agent loop itself - is a plugin mounted into a shared context object at runtime. A plugin claims a stable key on that context, such as ctx.tools or ctx.llm, and other plugins look up services by that key rather than importing a specific implementation directly. That indirection is what lets the DeepSeek API adapter be swapped for a different model provider without touching the filesystem or shell plugins around it.

In practice this means the plugin list you generate above works less like toggling settings on a fixed app and more like composing the app itself out of parts. Leave out the DeepSeek API adapter plugin and there is no LLM adapter claiming ctx.llm; the harness starts, but the agent loop has nothing to call.

Source: Cordis architecture description and the ctx.<key> service pattern, from the deepseek-harness Cordis tutorial and primer docs in the repository linked above.

Plugin lists load through the include plugin, published as @deepseek-ai/cordis-plugin-include. It reads a YAML or JSON file and turns it into loader entries, and will write updates back to that file when it is writable - so a config built by hand and one generated by dsh's own tooling can both round-trip through the same file. Each entry's name is a module specifier: either a relative path to a local plugin file, or an npm package name for a published one.

One detail that catches people the first time: the include plugin has to list itself, or nothing else in the file gets mounted. The generator above flags this if you uncheck it.

Source: the include-plugin config format described in the cordis-plugin-include docs, linked from the deepseek-ai/deepseek-harness repository.

The Node version range, the install commands, the Cordis service-key pattern and the include-plugin's config shape are all read directly from the deepseek-ai/deepseek-harness repository and its linked docs on August 17, 2026, not inferred from how similar tools usually work. The plugin catalog in the generator lists the categories the docs describe - a web UI, a model adapter, filesystem and shell tools, session persistence and the include loader itself - with each one's module specifier taken from the same sources.

What this page deliberately does not claim: exact GitHub star or fork counts, since those change by the hour on a project this new and any number printed here would be stale within a day. It also does not claim to have benchmarked dsh against Claude Code or any other harness - this is a developer preview, and a fair benchmark needs a settled release to compare against.