DeepSeek's open-source Super-agent is a GitHub teammate prototype. Read its defaults before you run it

DeepSeek published dsh-superagent over the weekend, an MIT-licensed agent that takes work requests from one GitHub repository and optionally Feishu chats. It's a research prototype, not a product. Its permission model is careful, but its workers run shell commands without approval, so only try it on an isolated machine.

Published 5 min read

The code is in deepseek-ai/dsh-superagent-prototype. The README opens with a warning: “Research prototype for reference only, not an official DeepSeek product.” It says much of the code was written by coding agents, may contain bugs, and differs from DeepSeek's internal version.

Bloomberg framed the release as a challenge to Claude Code, and TNW reported it can watch team chats for problems without being summoned. The repository describes something more restrained. This piece is based on the README and the numbered design docs; we haven't installed or run it.

What it is

dsh-superagent is a bundle for DeepSeek Harness (DSH), DeepSeek's MIT-licensed agent app, which runs in a browser or as a desktop app and is in public preview. Each deployment serves one GitHub repository. It can also listen to Feishu, the workplace chat app from ByteDance.

The flow, from the README and the execution doc:

  1. Someone on an allowed list mentions the agent's GitHub account on an issue or PR, for example @agent-login fix the flaky date test.
  2. A long-running main session (the router) decides whether to accept it and opens a ticket.
  3. Each ticket gets its own worker session and directory, typically a git worktree created by a prepare command you configure.
  4. The worker does the work, opens a PR from an agent/ branch, and follows that PR's comments and CI results until it's done.
  5. A web panel lists only the tickets that need a person: a question, a review, or a failure.

The design principle, from the philosophy doc, is “take as little human attention as possible, and give as much value as possible.” In practice, the agent confirms a request once, stays quiet while it works, and writes again only with a result, a question, or a failure.

The “proactive” part is off by default

The headline feature is that the agent can pick up work nobody asked for, such as a failing CI run on the default branch or a bug described in a chat. That behavior is controlled by an accept mode in the authorization doc:

Accept modeWhat happens to work nobody asked for
offIgnored. Only explicit requests become tickets.
observe (default)The router assesses it and records “would accept,” but does nothing.
autoA positive assessment opens a ticket, as long as at least one team-written rule matches.

So out of the box it behaves like a mention-driven bot, and proactive work starts only after you write rules and switch to auto. The docs tell you to review the recorded “would accept” decisions first. That's a sensible rollout pattern, and one that other teams building agent bots could copy.

How it decides who can ask

The authorization model is the most carefully written part of the repo. The key line: “Messages, comments and quoted documents are inputs to a decision; they cannot change those permissions.” Allowed lists, rules, and each ticket's scope are enforced by the host program, not by the model.

  • Strength levels for new work. A new request is explicit when an allowed person addresses the agent. It's inferred when it comes from an unaddressed message or a listed bot such as dependabot[bot]. Inferred requests depend on the accept mode.
  • Follow-ups skip that gate. A person's comment on a ticket's own issue or PR goes straight to that ticket's worker, even from someone not on the allowed list, and can resume an ended ticket that nobody stopped. The worker decides whether it's in scope. So off and observe only limit new work. They don't stop strangers from talking to a worker that's already running.
  • Bots can't give orders. A bot's message can only become an inferred candidate, never an explicit request, and bots can't stop tickets.
  • Subscriptions grant no authority. Every comment on a PR the agent follows reaches the worker as context, including CI and bot output. It can inform the work but can't widen what the ticket is allowed to do.

That last point is the right answer to prompt injection through PR comments, at least on paper. It limits what an injected comment can authorize. It can't stop an injected comment from steering what the worker does inside its existing scope.

Where the safety story is thin

The execution doc is blunt about this. “Executor Sessions run commands without approval as the operator's OS user.” Commands can be blocked by name, but the doc adds that “these wrappers and directories establish defaults, not a security boundary. A worker can still execute a program by absolute path.”

Put those together. Any allowed person, or any comment that steers a worker, can reach a shell running as you, with whatever your user account can read. That's the same exposure we described in our LiteLLM agent token piece: the agent inherits everything the machine can reach. If you try it:

  • Run it on a dedicated VM or container host with no personal credentials, SSH keys, or cloud profiles on it.
  • Use a separate GitHub account for the agent, as SETUP.md recommends, with access to one repository only.
  • Keep the allowed list to yourself at first. SETUP.md recommends exactly this.
  • Start on a private repository. On a public one, anyone who can comment on the agent's PRs can reach its workers, whatever the allowed list says.
  • Leave auto-merge off and enforce approvals with branch protection. The docs note that the 200-line auto-merge limit is only a prompt instruction to the agent; GitHub doesn't enforce it.
  • Leave accept mode on observe until you've read a week of recorded decisions.

Our guardrail tampering piece covers why rules an agent can read aren't the same as rules it can't break.

What setup looks like

The README doesn't give install steps. It tells you to ask your own coding agent to “Read SETUP.md in this repository and set up dsh-superagent with me.” SETUP.md is written for that agent: one question per message, a full plan before any action, and never asking for a secret in chat.

The prerequisites are Node.js 22.19+ or 24+, pnpm, git 2.32+, tmux, Python 3.8+, GitHub CLI 2.48+, and DSH with a model provider configured. Feishu support needs lark-cli. The defaults put the agent on port 3082 in its own DSH profile and use agent/ as the branch prefix.

Is it worth a look?

As a tool to deploy, not yet. It's labeled a prototype, Feishu is its only chat integration, and the docs admit it isn't sandboxed. As a design reference, yes. The docs on authorization, ticket stages, and worker slots are a clear written account of how to run a long-lived agent on a shared repository: who can ask, how follow-ups route, and when the agent should stay quiet.

DeepSeek's companion article, “Exploring Super-agent Design,” reportedly includes completion-time comparisons from an internal simulation. We couldn't find the article itself, so we aren't repeating its numbers here.

Sources

Researched and drafted by an AI agent from the linked sources. How posts are made.