DeepSeek has released the code for a coding agent that lives in a GitHub repository and answers requests with pull requests. The project, called Super-agent, was published on GitHub under the MIT license on 31 October, the same day DeepSeek's Harness team announced it in a WeChat post, according to ShiftDelete. ShiftDelete reported that the repository passed 4,000 stars within its first day, and by 2 November GitHub showed more than 10,600. For engineering teams, it is a rare chance to read how a major lab wires an agent that works inside a repository.
What Super-agent is
The repository describes Super-agent as a proactive coding agent for one GitHub repository, packaged as a bundle for DeepSeek Harness. Harness is DeepSeek's own open-source agent runtime, released under the MIT license and currently in public preview, which handles coding, research and scheduled tasks through plugins. Super-agent listens to GitHub and, optionally, to Feishu group chats, the workplace chat app known outside China as Lark. When someone on an allow-list asks for work, the agent opens a work item, works on it in its own agent session and directory, and answers in the original conversation, for example with a pull request. A web panel shows what needs a person.
The documentation describes a main "router" session that talks to people and routes requests, and separate "worker" sessions, one per task, that can run in parallel. An hourly check restarts the agent if it stops running. ShiftDelete also describes a Watchdog process that looks for failures and stuck loops. That split between one coordinator and many workers is worth understanding even if you never run this code, because it is a common way to build agents that handle several jobs at once.
The idea behind it
The README states the design goal plainly: take as little human attention as possible, and give as much value as possible. DeepSeek's reasoning is that an agent acting for a whole team can also waste a whole team's attention. Super-agent therefore acts only when asked or when a rule the team wrote allows it, and speaks only when someone must act or can use a result. Teams evaluating any coding agent can borrow that test, whichever product they choose.
What DeepSeek says it is not
DeepSeek is unusually direct about the limits. The repository opens by calling it a research prototype for reference only and says it is not an official DeepSeek product. It warns that the code may contain bugs and that its coding style may be inconsistent, and says much of the engineering was done by coding agents. The public version was adapted for publication, so it differs from the version DeepSeek uses internally, and some designs in DeepSeek's companion article, "Exploring Super-agent Design", are not implemented. ShiftDelete reports that Bloomberg framed the release as a challenge to Anthropic's Claude Code. DeepSeek has not made that comparison in the repository.
What you need to run it
The setup guide is written for a coding agent to follow together with the person installing it, which tells you something about how DeepSeek expects people to work. It lists these requirements:
- Node.js 22.19 or later (or 24 and later), pnpm, git 2.32 or later, tmux, Python 3.8 or later and the GitHub CLI 2.48 or later.
- DeepSeek Harness with a model provider configured.
- A repository on github.com. The deployment guide says GitHub Enterprise Server is not supported.
The guide also builds in safeguards. It recommends a dedicated GitHub account for the agent, keeps auto-merge off by default, limits who can request work to an allow-list, and starts in an observe mode that records proactive work without doing it.
The security section deserves a careful read. The deployment guide says the agent's sessions run with full access as the operator's own computer user, run commands without asking for approval, and can read that user's home directory. It adds that its account wrappers are not a security boundary. For real isolation, DeepSeek recommends running the agent under a separate operating system account that holds only the agent's credentials.
Why it matters
An agent that sits inside a repository, picks up requests from issues or chat and comes back with a pull request changes who writes the first draft of routine work, so the details of permissions and attention matter more than the demo. A readable, permissively licensed example from a major lab lets a team study the moving parts, from permissions to how the agent decides when to speak, before it buys or builds anything. We think the design pattern, more than this particular code, is the valuable part of the release.
What to do this week
If you lead an engineering team, read the README, the philosophy document and the deployment guide's permissions section before anyone installs it. If your security team reviews new tools, give them that section first. If you want to try it, use a test repository that nobody depends on, run it on a separate operating system account, give the agent its own GitHub account, start in observe mode and keep auto-merge off so a person reviews every pull request. For a wider look at the coding tools people use today, see our comparison page, and for a recent reminder of why agent permissions matter, read our piece on the tampered Claude Code extension.