DeepSeek's dsh-superagent Waits to Be Asked, Then Works Each GitHub Request in Its Own Session Without Asking Again

DeepSeek has released the code for a coding agent built around one rule: cost the team as little attention as possible. The repository, deepseek-ai/dsh-superagent-prototype, appeared on GitHub on October 31, 2026, at 15:02 IST under the MIT license. By early on November 1 it had passed 2,300 stars and 200 forks.

The README opens with a warning in bold: “Research prototype for reference only, not an official DeepSeek product.” It says the code “grew out of our team’s day-to-day development work, with much of the engineering done by coding agents,” and that it differs from DeepSeek’s internal version. It also says some ideas in the companion article, Exploring Super-agent Design: Towards a More Autonomous Agent System, are future directions that the prototype does not implement.

A bundle for DeepSeek Harness

dsh-superagent is “a proactive coding agent for one GitHub repository,” packaged as a bundle for DeepSeek Harness (DSH), the company’s agent runtime. It listens to GitHub and, optionally, Feishu, the ByteDance workplace chat app. When an allowed person asks for something, it opens a work item, does the work in its own session and directory, and answers in the original conversation, for example with a pull request. A web panel shows only what needs a person.

The setup guide lists Node.js 22.19+ or 24+, pnpm, git 2.32+, tmux, Python 3.8+, GitHub CLI 2.48+ and a compatible DSH version, plus a model provider. The README suggests letting a coding agent follow SETUP.md with the user. The guide also says the agent should run under a dedicated GitHub account, “never the operator’s own,” because everything it writes appears under that name.

Attention as the design budget

The philosophy document states the core principle as “Take as little human attention as possible, and give as much value as possible.” Every message, notification, setting and panel element has to give more value than the attention it costs, “or it is removed.”

That turns into concrete behavior. The agent acts only when someone allowed addresses it directly, or when a rule the team wrote permits proactive work. It confirms a request once, stays quiet while working, and writes again only when a result is ready, it needs a decision, or it cannot finish. The document tells operators to start with a short allowed list and warns against using the agent for “mass pull requests, broadcast messages and busywork.”

Who gets to start work

The authorization document says the host, not the model, enforces allowed lists, rules and Mandates, the record of what each ticket may do. “Messages, comments and quoted documents are inputs to a decision; they cannot change those permissions.”

Incoming messages get a strength. An allowed person who mentions the agent makes an explicit request. A bot on a configured list, such as dependabot[bot], can only produce an inferred candidate, and other bots are not admitted. Each GitHub scope has an admission table that decides how unlisted people are treated, and by default unlisted people are ignored.

Proactive work runs through three accept modes. In off, nothing inferred becomes a candidate. In observe, the default, inferred candidates are assessed and a positive result is recorded as “would accept,” but nothing starts. In auto, a positive assessment starts work. The docs recommend staying in observe until the recorded decisions look right.

What a worker is allowed to do

Each accepted ticket gets an Executor Session named worker-<ticket id> and its own directory, and a team-supplied prepare command, typically git worktree, can create a checkout before work begins. Launches run concurrently up to a configured limit, with one extra slot kept free so a person’s follow-up is never stuck behind new work.

The execution document is direct about the trade-off: “Executor Sessions run commands without approval as the operator’s OS user.” Foreground shell commands move to the background after five seconds so the worker can read new messages, and background jobs have at most 30 minutes after each turn before they are killed and the ticket is reported waiting.

Merging stays conservative by default. The stock instructions allow auto-merge only for the ticket’s own pull request, once required approvals cover the head commit and the change is under 200 added plus deleted lines. The docs note that these are instructions to the agent, not GitHub rules, and tell teams to enforce approvals in branch protection.

No benchmarks, just the gatekeeping

The repository includes no benchmarks, and DeepSeek makes no claims about how well the agent codes. What it does publish is a detailed account of the gatekeeping around a coding agent: who may wake it, how its permissions are recorded, and when it may speak. Because workers run commands unprompted under the operator’s account, anyone trying it should use an isolated machine or container with no personal credentials.