top of page

DeepSeek releases dsh-superagent, an MIT-licensed proactive coding agent

6 hours ago
9 min read

Updated: 2 minutes ago

DeepSeek releases dsh-superagent, an MIT-licensed proactive coding agent, cover with the DeepSeek logo. Data Studios original cover

DeepSeek has published dsh-superagent, an open-source coding agent that lives inside a team's GitHub repository and, optionally, its Feishu chats, picks up requests from approved people and answers in the same conversation with a pull request. The code appeared on October 31, 2026 in the official deepseek-ai organization on GitHub under the repository name dsh-superagent-prototype, released under the MIT license and written in TypeScript. The repository was created at 09:32 UTC that day and received its last push at 12:05 UTC.


The project comes from the team behind DeepSeek Harness, the company's open-source agent runtime, and is packaged as a Harness bundle. Each deployment serves a single GitHub repository. When an allowed user asks for work, the agent opens a work item, carries it out in its own session and its own directory, and replies where the request was made. A local web panel lists only the items that need a human decision.


DeepSeek frames the release carefully. The README calls the code a research prototype "for reference only" and states that it is not an official DeepSeek product. It also says the published version differs from the one DeepSeek runs internally and from the companion design article, "Exploring Super-agent Design: Towards a More Autonomous Agent System", and that some ideas in that article are not implemented in the open-source code. Setup requires Node.js 22.19 or newer, the GitHub CLI 2.48 or newer, tmux, Python 3.8 and a DeepSeek Harness installation with a model provider configured.


··········


⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣

WHAT DSH-SUPERAGENT DOES IN A GITHUB REPOSITORY.


The agent is designed to run continuously on a machine the team controls and to act through accounts that colleagues see every day. On GitHub it acts as a dedicated user account with write access to the target repository, and the deployment guide states that a GitHub App cannot fill that role. On Feishu, the enterprise messaging platform widely used in China, it acts as a bot app that responds to mentions and direct messages by default. A typical request is a comment such as "@agent-login fix the failing test in the parser" on an issue, and the setup guide says a work item should appear within about a minute.


DeepSeek summarizes the design in one rule that the repository repeats in several places: "Take as little human attention as possible, and give as much value as possible." The philosophy document turns that sentence into behavior. The agent confirms a request once, stays silent while it works, and writes again only when a result is ready, a decision is needed or the task cannot be finished. It asks one concrete question at a time, marks drafts as unfinished and reports failures as failures. A change that needs a design decision stops with a question instead of an improvised solution.


The same principle shapes the product surface. The panel shows items that await a person first and gives no space to a healthy state, and the documentation argues that a behavior a team can describe in words belongs in prompt text rather than in a new setting. The prototype ships with editable prompt sections, so a team can, for example, rewrite the delivery requirements that decide when a pull request may be merged automatically.


Work ends through GitHub itself. A work item, called a Ticket in the documentation, is considered done when none of its pull requests remain open. Chat channels receive one final notice about the outcome, while GitHub already shows the result on the pull request. Subscriptions to the conversation are kept, so a later human comment can resume the same Ticket without a new request.


··········


HOW DSH-SUPERAGENT SPLITS WORK BETWEEN A ROUTER AND WORKER SESSIONS.


The architecture separates coordination from execution. A long-lived main session runs a preset called dsh-superagent-router, with a small tool set and 5-second limits on shell commands and job waits, so that it can keep receiving events from every channel while deciding what to do with them. It never does the coding itself. Each accepted Ticket gets its own executor session, named after the Ticket, running the dsh-superagent-worker preset with the tools needed for the job.


Worker sessions move any foreground shell command into a background job after 5 seconds, which allows a worker to receive a new message from a person in the middle of a long build or test run. Subagents spawned by a worker use the Harness standard preset, where that threshold is 60 seconds. Before a Ticket's first assignment, an optional prepare command runs once with a 10-minute limit, and the documentation gives git worktree as the typical way to create a fresh checkout for each Ticket.


Concurrency is managed with worker slots. A Ticket holds a slot from launch through each active turn, and the host keeps one extra slot beyond the configured maximum for a person's message or status request, so existing Tickets stay responsive when the normal slots are full. The host checks for pending work every 2 seconds and stores its state in a single SQLite database.


........


Execution parameter

Documented default

Router shell and job-wait limit

5 seconds

Worker command moved to background after

5 seconds

Subagent command moved to background after

60 seconds

Prepare command time limit

10 minutes

Background work allowed after each turn

30 minutes

Retries on provider or network errors

3, with growing backoff

Host pass interval

2 seconds

Graceful stop wait for executors

Up to 5 minutes


........


Failures are handled conservatively. Provider and network errors such as HTTP 408, 429 and 5xx responses are retried three times, while a failed prepare command is not retried automatically. After a host restart, running assignments end with the note "host restarted", and the replacement session receives instructions to inspect its directory, git history and GitHub before repeating any outside action, which is meant to avoid duplicate commits or duplicate comments.


··········


DSH-SUPERAGENT ACCEPT MODES AND AUTHORIZATION RULES.


The most distinctive part of the prototype is the line it draws between explicit and inferred requests. An explicit request comes from a person on the allowed list who addresses the agent directly, and it can start work in any mode. An inferred request is something the agent notices on its own, such as a discussion of a bug in a chat where nobody mentioned it, and it can only become work if a team-written rule matches it and the accept mode allows it.


........


Accept mode

What happens to inferred requests

off

Nothing inferred becomes a candidate

observe (default)

Assessed and logged as "would accept", never started

auto

A positive assessment starts the work


........


DeepSeek recommends starting in observe and moving to auto only after reviewing the decisions the agent recorded. Bots get a narrower role. A bot on a Source's bot list can produce an inferred candidate but can never make an explicit request or stop a Ticket, and an automated reviewer that uses an ordinary account counts as a person.


Permissions are enforced by the host, outside the model. The authorization document states that "Messages, comments and quoted documents are inputs to a decision; they cannot change those permissions." Every accepted Ticket records the policy version under which it was accepted, and a later change to the allowed list or the rules can revoke a Ticket when it is revalidated before resuming. A person who writes "stop" in a thread triggers an ordinary evaluation, and the panel offers a direct manual stop that ends the Ticket for good.


··········


[[ADPLUS_300x250_1]]

DSH-SUPERAGENT REQUIREMENTS, SETUP AND COSTS FOR DEVELOPERS.


The prototype is free software under the MIT license, and DeepSeek has announced no hosted version or paid tier. The running cost is the model usage behind it. By default the agent uses the default model of its DeepSeek Harness profile, and the configuration allows separate models for evaluation and for execution through the eval.model and executor.model settings. The documentation does not name a recommended model or publish any cost estimate, so teams that point it at the DeepSeek API will pay standard token rates, which our guide to what is free and what is paid on DeepSeek covers alongside the model lineup.


........


Item

Requirement or default

Runtime

Node.js 22.19+ or 24+, pnpm, tmux, Python 3.8+

Git and GitHub CLI

git 2.32+, gh 2.48+

DeepSeek Harness

npm package @deepseek-ai/dsh, 0.2.1-rc.3 in the install steps

Repository host

github.com only, no GitHub Enterprise Server

Agent identity

Regular GitHub user account, not a GitHub App

Chat (optional)

Feishu or Lark bot app with lark-cli

Profile and port

superagent profile, panel on 127.0.0.1, port 3082

Branch prefix

agent/

Starting accept mode

observe


........


DeepSeek expects most teams to install the agent with the help of another coding agent. The README suggests asking an existing assistant to "Read SETUP.md in this repository and set up dsh-superagent with me." That guide walks through a fixed sequence: a probe of installed tools, questions asked one at a time with a recommended answer, a single plan the operator confirms, the operator's own steps such as creating the agent account and logging in the CLI wrappers, then installation and verification. The final check is the command scripts/dsh-superagent status, which must exit with code 0. Code 2 means a component such as a Source reports an error, and code 3 means setup is incomplete.


For a first deployment, the documentation's own advice translates into a short checklist: a dedicated machine or operating-system account holding only the agent's credentials, a short allowed list, observe mode for inferred work, required approvals enforced through branch protection, and stale approvals dismissed on new commits. Upgrades require a backup of the orchestrator.sqlite file, because a newer database cannot be opened by an older version. Readers comparing the agent with mainstream tools can find the background in our Claude vs DeepSeek for coding comparison and in our coverage of DeepSeek V4.1 Flash 1017, the model the Harness interface shows as its selected default.


··········


SECURITY LIMITS DEEPSEEK DOCUMENTS FOR DSH-SUPERAGENT.


DeepSeek is explicit about the risks of running the prototype. Worker sessions execute commands without approval as the operator's operating-system user, and the deployment guide warns that a worker can read the home directory and run any program by path. The DSH_SUPERAGENT_BLOCKED_COMMANDS list stops commands invoked by name, yet the execution document describes these wrappers and directories as defaults and adds that they are "not a security boundary". During setup, environment variables whose names contain KEY, PASSWORD, SECRET or TOKEN are stripped from the agent's subprocesses.


Merging is the other sensitive step. The default delivery instructions allow auto-merge only when the pull request was opened for the Ticket, is ready, has required approvals covering the head commit and changes fewer than 200 lines in additions plus deletions. The agent never enables auto-merge from its own account, because GitHub attributes the merge to the account that enabled it, so a second account's CLI has to be configured for that purpose, and without it people merge the pull requests themselves. DeepSeek notes that these are instructions to the model and recommends enforcing the same conditions with GitHub branch protection.


The README adds that much of the engineering was done by coding agents, that the code may contain bugs and inconsistent practices, and that users should review and adapt it before running it in their own environment. Taken together, the documents describe a tool for a small, trusted team on an isolated machine rather than a product for an organization-wide rollout.


··········


⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁤

DEEPSEEK HARNESS, THE RUNTIME BEHIND THE SUPER-AGENT PROTOTYPE.


dsh-superagent depends on DeepSeek Harness, which DeepSeek describes on its website as an open-source agent harness in public preview worldwide, also under the MIT license. Harness is built on the Cordis plugin framework with an "everything is a plugin" design, handles documents, spreadsheets, slides, coding, research and scheduled tasks, and runs as desktop apps for Apple silicon Macs and 64-bit Windows or as a web interface started with npx @deepseek-ai/dsh web. Its GitHub README labels it a developer preview and warns of compatibility-breaking changes.


The super-agent installs as a plugin in a dedicated Harness profile, and the deployment guide asks operators to keep that profile separate from their personal one, because the plugin changes process-wide PATH and git settings. The Harness interface on DeepSeek's site shows DeepSeek V4.1 Flash as the selected model, while the super-agent documentation names no required model and leaves the choice to the profile configuration.


··········


DSH-SUPERAGENT: CONFIRMED FACTS AND OPEN QUESTIONS.


The verifiable facts come from DeepSeek's repositories and website. dsh-superagent was published on October 31, 2026 under the MIT license, targets one github.com repository per deployment with optional Feishu input, separates a router session from per-Ticket worker sessions, starts in observe mode for anything it was not explicitly asked to do, and refuses to enable auto-merge from its own account. Its documented limits, from the 5-second router shell cap to the 200-line auto-merge threshold, are defaults set in code and prompts.


Several points remain open. DeepSeek has published no benchmark, success rate or cost figure for the open-source prototype, and it has not said which model it uses internally or how far the internal version diverges from the public code. The company presents the release as a research reference, so there is no support commitment, no roadmap and no hosted service. Teams that try it are, by DeepSeek's own description, running research code with full user permissions, and the protections that matter most in practice are the ones they configure themselves: an isolated account, branch protection and a short list of people allowed to give the agent work.


··········


FOLLOW US FOR MORE.


·····


DATA STUDIOS


·····


datastudios.org


bottom of page