DeepSeek dsh-superagent: The Proactive GitHub Coding Agent It Just Open-Sourced

DeepSeek has published dsh-superagent-prototype, an MIT-licensed bundle for DeepSeek Harness that turns requests on GitHub, and optionally Feishu, into agent work items and pull requests. The repository was a single commit with about 130 stars at the time of writing, and the README is blunt about its status: "Research prototype for reference only, not an official DeepSeek product." It also warns that the code "grew out of our team's day-to-day development work, with much of the engineering done by coding agents."

That candor is the first reason to read it. The second is the design: instead of another chat window, it is a framework for an agent that acts for a whole team and tries to cost as little of the team's attention as possible. If you followed our earlier coverage of the first DeepSeek Harness plugin stack, this is the first large public example of what you can build on top of it.

TL;DR: questions people will ask

What it does

The README describes the agent as one that "listens to GitHub and, optionally, Feishu." When someone allowed asks for work, it opens a work item, does the work in its own agent session and directory, and answers in the original conversation. A web panel shows what needs a person.

The numbered docs explain the vocabulary. From the authorization and execution documents:

• Source: where requests come from (GitHub, Feishu). A Source records whether a message mentions the agent or is a direct message.
• Trigger and Eval: a message is evaluated to decide whether to start work. An allowed person who addresses the agent makes an explicit request. Bots on a Source's bot list can only produce an "inferred candidate", never an explicit request, and other bots are not admitted.
• Ticket: an accepted unit of work. Each open ticket has one stage determined by what it is waiting for, with panel labels such as Awaiting answer, Awaiting review, Blocked or Failed, Queued, Waiting for a Trigger, or Working.
• Executor: each ticket gets its own session named worker-<ticket id> and its own directory under the execution root.
• Mandate: the permission envelope. The host enforces allowed lists, rules and Mandates; "messages, comments and quoted documents are inputs to a decision; they cannot change those permissions."

That last rule matters. A message from a comment thread is treated as data for a decision, not as authority, which is the same discipline we recommend against indirect prompt injection.

The philosophy: spend as little human attention as possible

The philosophy document opens with one principle: "Take as little human attention as possible, and give as much value as possible." Every message, notification, setting and panel element is judged by the attention it costs.

Concretely, the agent:

1. Acts only when asked or when a written rule allows it. Work nobody asked for needs a rule the team wrote, and starts in a mode that only records what the agent would have done.
2. Speaks only when a person must act or can use a result. It confirms a request once, stays quiet while it works, and writes again when a result is ready, a decision is needed, or it cannot finish.
3. Asks one concrete question at a time, in a structured form.
4. Stops by impact, not by effort. A local change goes as far as a reviewable result; a design decision stops with a question.
5. Reports honestly. A draft is marked unfinished, a failure is a failure, and a limit is never bypassed to avoid asking.

On the design side it wants few concepts, few settings (defaults replace a setting when one value suits almost every team), a panel where "a healthy state takes no space", and docs that read in order.

This is a different bet from the OpenBot desktop workspace or the Rakazo bring-your-own-model bot, which centre on a single user's desktop. Here the unit is the team conversation.

Two shapes reviewing one sheet with a green check, an image for a coding agent whose pull requests wait for human review

How execution works

The execution doc shows how much operational detail the authors had to work through:

• Delivery of input to an Executor that fails is retried after 2 seconds, then after a delay that doubles up to a minute.
• Executor sessions use a dsh-superagent-worker preset; the main session uses dsh-superagent-router with a smaller tool set. Foreground shell commands move to background jobs after 5 seconds so a worker can receive new messages at its next step.
• When a turn ends with shell jobs or subagents still running, the ticket keeps its worker slot. Background work gets at most 30 minutes after each turn; at the limit, shell jobs are killed and the ticket is reported waiting.
• A handoff to a person frees the slot immediately and stops subagents; shell jobs such as a server offered for review may keep running until the assignment ends.

Follow-up messages are another subtle area. A person's message on a ticket's own thread belongs to that ticket's Executor, which either handles it within scope or hands it back for fresh routing. While an Executor owns the message, the main session can only stop work, not reroute it.

Risks and what to do before you try it

The responsibility section of the philosophy doc is the honest part: "The agent comments, opens pull requests and messages people under accounts your team sees every day. Every message it sends costs your colleagues' attention, and you are responsible for it."

Specific cautions drawn from the repo:

• No approval prompts. The execution doc says Executor Sessions run commands without approval as the operator's OS user. Run it on an isolated machine or container, not your daily laptop with SSH keys and cloud credentials.
• Use a dedicated GitHub account. The setup guide recommends a dedicated account for the agent, "never the operator's own", because everything it writes appears under that name.
• Start narrow. The authors recommend a short allowed list (initially only the operator) and recording proactive work before letting it act.
• Do not use it to produce volume. The docs specifically warn against mass pull requests and busywork.
• Version coupling. It is built for a DeepSeek Harness version within the engines.dsh range in its package.json; check that before installing.
• Secrets. The setup guide says never to ask for a secret in chat; steps needing the operator's hands go into one message with exact terminal commands.

If you are building guardrails for agents like this, AgentBeam is the agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions.

How to try it

The README is unusual about setup: "Setup has many steps, so an agent does it with you." Ask your coding agent: "Read SETUP.md in this repository and set up dsh-superagent with me." The guide instructs that agent to ask one short question at a time with a recommended answer, show the full plan once, and then install and configure.

The prerequisites it probes for are Node.js 22.19+ or 24+, pnpm, git 2.32+, tmux, Python 3.8+, GitHub CLI 2.48+ and DeepSeek Harness itself, plus a model provider. A missing tool becomes part of the plan, not a question. The questions follow the flow of work: where requests come from (GitHub only is recommended unless your team lives in Feishu), which owner/name repository, which agent account, who may ask for work (just you at first), and which local clone the Executor works from.

For development, pnpm check runs the typecheck, the tests and the build.

Why it matters

Most coding agents so far wait for a prompt. DeepSeek's prototype asks what happens when an agent is a teammate: how it is authorized, how it avoids spamming colleagues, how it hands work back, and how a human sees only what needs them. Those problems appear in every serious attempt to run agents in a team workflow, including the ones we compared in our proactive agents roundup.

It also shows DeepSeek investing in the agent layer, not only models. The harness is where its team iterates on prompts, approval gates and sessions, and a bundle format means third parties can extend it. For context on the lab's security posture, see our reading of the CrowdStrike report on a DeepSeek-linked campaign, a separate story but relevant if your security team asks about adopting a DeepSeek-built tool.

What is not here

• No benchmark, productivity number or case study; the repo makes no performance claims.
• No pointer we could verify to a published design paper beyond the title the README names, and a web search did not turn up that article, so treat the README as the source of truth.
• Some designs from the article are "directions for future development and are not implemented".
• A single commit and about 130 stars means no track record of maintenance yet.

We will add an update if DeepSeek publishes the design article or tags a release.

Related reading

• DeepSeek Harness Desktop for macOS and Windows
• DeepSeek Harness v0.1: the plugin-first agent stack
• Proactive agents compared: Claude Duet, OpenAI Dots, Meta Muse, Grok Bot
• OpenBot by Nightly Labs
• Indirect prompt injection explained
• What is MCP?
• Sources: dsh-superagent-prototype on GitHub, philosophy doc, authorization doc, execution doc

Repository details, star counts and requirements are accurate as of October 31, 2026 and may change.