Back to Home

DeepSeek Harness: Everything Is a Plugin. Here's How

DeepSeek's newest open-source drop is not a model. It is the scaffolding around the model, and it ships with an idea that is either obviously right or quietly radical depending on how many config files you have written this year: everything is a plugin.

The project is called DeepSeek Harness, or dsh for short. It is a developer-preview agent runtime released under the MIT license, with its source code on GitHub at deepseek-ai/deepseek-harness. If you have been treating your coding agent as a black box with a settings menu, dsh is the opposite: a harness where the model plugs in at one end and every other capability (tools, skills, sessions, sandboxes, storage, loops, scheduling, even the UI) is a swappable module at the other.

What DeepSeek Harness Actually Is

Start with the equation DeepSeek repeats on its own project page: agent = model + harness. The model is the soul, the company says, but a harness is what lets that soul understand its environment, call tools, and keep working in real-world settings. Most vendors ship a fixed harness and let you tune it. DeepSeek shipped a harness where tuning is the entire design.

The engine underneath is a plugin kernel called Cordis. It handles mounting, unmounting, and dependency resolution for plugins, while the actual agent capabilities live inside those plugins. The practical consequence is that a plugin is just a JavaScript or TypeScript module exporting an apply(ctx, config) function. Whatever that function registers on the context object determines what the plugin becomes.

That single mechanism replaces the usual pile of formats. Where a typical agent tool needs one file for tools, another for slash commands, another for skills, and another for MCP server connections, dsh collapses all four into code that calls ctx. DeepSeek even ships bridge plugins, dsh-hooks-claude-code and dsh-hooks-codex, that translate an existing Claude Code or Codex hooks.json into dsh's own hook points, so you can reuse what you already wrote instead of rewriting it.

Your First Five Minutes With dsh

You do not need to clone anything to see it move. The fastest path is a single command from npm, which launches the web interface and listens on localhost by default.

  1. Install Node.js, then run npx @deepseek-ai/dsh web to start the web UI on http://127.0.0.1:3080.
  2. To build against the newest framework code, clone github.com/deepseek-ai/deepseek-harness, then run pnpm install, pnpm run build, and pnpm dsh web.
  3. Pick a mode: Standard for the full toolset, Code to let the model orchestrate multi-step tool calls as one TypeScript program, Minimal for a two-tool benchmark environment, or Creator to inspect the runtime and test plugins in memory.
  4. Open the Trajectory view and watch the append-only session log, which records system prompts, reasoning, tool calls, results, subagent scheduling, and every context injection.

That last step is the one worth slowing down for. Because every run is traceable on a single event stream, resume, fork, search, and replay all operate on the same records. If your agent misbehaves, you are not guessing at what it saw; you are reading it.

Profiles, Plugins, and the Directory Nobody Owns

Configuration is organised into profiles. A profile is a named, runnable setup living under $DSH_HOME/profiles/<name> (with $DSH_HOME defaulting to ~/.dsh) that lists which plugin bundles are active and in what order. That lets a lean headless automation profile and a plugin-loaded web profile coexist without stepping on each other.

Launching against a profile is a flag away. Running dsh web is shorthand for --profile web, while dsh --profile headless "<task>" fires a one-shot task with no interface at all. To add a plugin, the command is dsh plugin --profile <name> add <specifier>, and it accepts npm packages, GitHub repositories, or local paths.

Here is where the ecosystem gets interesting, and where you need to be a little careful.

  • DeepSeek runs no official plugin marketplace or registry for dsh.
  • The only first-party discovery convention is a GitHub topic: plugin authors tag their repository with dsh-plugin.
  • There is no central review and no official list, so plugin quality stays a community matter.
  • The community's answer is awesome-dsh-plugin, a hand-reviewed directory tracking roughly 365 plugins across 11 categories, from UI enhancements and developer tooling to memory and workflow automation.

For anyone used to installing extensions from a curated store, that is a real adjustment. The upside is that a dsh plugin is plain code, not a packaged binary waiting on a vendor's approval, which is exactly the trade DeepSeek is asking developers to make.

Two caveats before you standardise on it. dsh is still in developer preview, so the project's own documentation warns you to expect compatibility-breaking changes as the framework iterates. And "everything is a plugin" cuts both ways: flexibility you did not ask for is still configuration you have to own.

Still, the pitch is hard to argue with. Most agent tools ask you to accept their opinions about tools, memory, and orchestration. DeepSeek Harness asks you to replace them. For teams already maintaining a pile of harness forks, that is less a product launch than a permission slip, and the command you need to test it fits in a single terminal line.

Comments

No comments yet. Be the first to share your thoughts!