dsh-superagent comes from DeepSeek's Harness team. It is MIT licensed, went public on 31 October 2026 and had 20,216 stars on GitHub on 7 November 2026. The README says it grew out of the team's day-to-day work, "with much of the engineering done by coding agents".
Tag it on an issue. Get back a pull request you review.
If your team ships to production, or you are the person everyone pings to fix things, the slow part is rarely writing the fix. It is noticing the report, picking it up, and remembering to come back to it. This agent is built to take that part, and to stay quiet until you need to look.
// Build this with your AI agent
Build this with your AI agent
The project is designed to be set up by a coding agent with you. Copy this prompt into Claude Code, Codex or any coding agent, together with this guide's link.
Read this guide: https://codewithnishant.dev/free/deepseek-super-agent-setup/ and the official repository https://github.com/deepseek-ai/dsh-superagent-prototype. Clone the repository, then read SETUP.md in it and set up dsh-superagent with me, following SETUP.md exactly. Use a test repository first, not my production repo. Recommend GitHub only as the source, a separate agent GitHub account, only my own GitHub login on the allowed list, observe mode for proactive work, and no auto-merge. Ask me one question at a time, show me the full plan once, and do not install anything before I confirm. Never ask me for a password, token or secret in the chat: give me the exact commands to run in my own terminal instead. When it is running, tell me how to tag the agent on an issue to test it. Tell me what is not working instead of guessing.
01. What it is
From the README: a proactive coding agent for one GitHub repository, packaged as a bundle for DeepSeek Harness, DeepSeek's open source agent app. It listens to GitHub and, if you want, Feishu chats. When someone allowed asks it for work, it opens a work item, works on it in its own agent session and folder, and answers in the original conversation, for example with a pull request. A web panel shows what needs a person.
| What | The fact (checked 7 Nov 2026) |
|---|---|
| Made by | DeepSeek's Harness team, as a research prototype. The README says it is not an official DeepSeek product |
| Price | Free, MIT license. You pay for your own model use |
| Listens to | One github.com repository, plus Feishu chats if you turn them on |
| Runs on | DeepSeek Harness, with the model your Harness profile is set to |
| Repo | deepseek-ai/dsh-superagent-prototype, 20,216 stars, last push 3 November 2026 |
The README also says the published code is not identical to DeepSeek's internal version, and that some ideas in their design essay are future directions that this prototype does not implement.
02. How it works
The idea behind it, in DeepSeek's words
The principle in docs/000-philosophy.md is to "take as little human attention as possible, and give as much value as possible." In practice:
- It acts only when asked, by someone on the allowed list, or when a rule your team wrote allows it. Work nobody asked for starts in a mode that only records what it would have done.
- It speaks only when you 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, when it needs a decision, or when it cannot finish.
- Every task gets its own worker. Per docs/003-execution.md, each work item gets its own session named
worker-<ticket id>and its own folder, usually a git worktree, and several run at once up to a slot limit. - The panel shows only what needs a person: awaiting answer, awaiting review, blocked or failed, then system health and history.
DeepSeek's design essay, Exploring Super-agent Design, adds the bigger picture: a person can follow only about three to five agent sessions at once, so a router session handles people and hands out work without doing it, workers do the tasks, and a separate watchdog checks that workers are making real progress. In the essay's early tests on synthetic tasks, the slowest tasks (p95) finished in 15.7 minutes against 29.5 minutes for a single session. Those are DeepSeek's numbers, not a test of mine.
03. Before you install
From docs/006-deployment.md:
- Tools: Node.js 22.19+ or 24+, pnpm, git 2.32+, Python 3.8+ and tmux. GitHub CLI (
gh) 2.48 or later. - A repository on github.com. GitHub Enterprise Server is not supported. Keep a local clone the agent can make worktrees from.
- DeepSeek Harness with a model provider. The agent uses your profile's default model unless you name another.
- A separate GitHub user account for the agent, with write access to the repo. A GitHub App cannot be the agent, because it reads the account's notifications. Everything it writes shows up under this name, so never use your own account.
- Optional:
lark-cliand a Feishu or Lark bot app, if your team works in Feishu.
04. Set it up on your repo
Way A is DeepSeek's own recommendation
Way A: let your coding agent run SETUP.md with you
The README says setup has many steps, so an agent does it with you. Clone the repo, open it in your coding agent, and ask:
git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git
cd dsh-superagent-prototype
# then, in your coding agent:
Read SETUP.md in this repository and set up dsh-superagent with me.SETUP.md tells the agent to ask one question per message, show the full plan once, and execute only after you confirm. It never asks for a secret in the chat. The questions, in order:
- Sources: GitHub only, or Feishu too. Recommended: GitHub only.
- Repository as
owner/name. - Agent account: the GitHub user it acts as. Recommended: a dedicated account, never yours.
- Who may ask for work on GitHub. Recommended: only your own login at first.
- Checkout: which local clone each task checks out from. Recommended: a new clone under
~/src/<name>. - Commit identity. Recommended: the agent account, so its work is visibly its own.
- Auto-merge. Recommended: no. People merge until its pull requests have been right for a while.
Defaults it fills in without asking: a separate Harness profile called superagent on port 3082, branch prefix agent/, accept mode observe (proactive work is recorded, not done), and an hourly check that restarts it if it stops.
Way B: the manual install
If you would rather do it by hand, the deployment doc's install block, run once on a machine with no superagent profile yet:
npm install -g @deepseek-ai/[email protected]
git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git dsh-superagent && cd dsh-superagent
pnpm install && pnpm build
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"The fourth command creates the superagent profile and replaces it if it already exists, deleting its machine configuration, so never run it for an upgrade. The pinned Harness version was current on 7 November 2026; check the doc for a newer one. Then copy examples/profile.cordis.patch.yml into the profile, fill in the placeholders, and follow the doc's Accounts, Start and stop and Management API sections.
The agent's GitHub CLI
The doc gives the agent a GitHub CLI wrapper that only uses its own login. Sign in as the agent account, not as yourself:
mkdir -p ~/.local/bin
cat > ~/.local/bin/gh-agent <<'EOF'
#!/bin/sh
GH_CONFIG_DIR="$HOME/.config/gh-agent" exec gh "$@"
EOF
chmod +x ~/.local/bin/gh-agent
gh-agent auth login
gh-agent api user --jq .loginCheck it worked
Per SETUP.md, scripts/dsh-superagent status should exit 0 with no setup problem. Then open the Superagent entry in the DeepSeek Harness web sidebar. That panel is where you look from now on.
05. What to let it touch
This is the part that decides whether the agent saves your team time or creates noise and risk. Everything below comes from DeepSeek's own docs.
| Setting | Start with | Why |
|---|---|---|
| Repository | A test repo, then one real repo | It works on exactly one github.com repo |
| Who may ask | Only you | It acts for people on the allowed list only. Short list, less noise while you learn how it behaves |
| Proactive work | observe | Records what it would have done, without doing it. Widen only once that looks right |
| Merging | People merge | It never enables auto-merge as its own account. If you allow it later, the default rules limit it to its own ready, approved pull requests under 200 changed lines |
| Agent account | A dedicated GitHub user with write access to that repo only | Everything it writes appears under this name |
| Machine | A separate machine or OS user | Workers run commands without approval as the operator's OS user, and the docs say its folders are defaults, not a security boundary |
| Secrets | None from production | Anything the machine can read, a worker can read |
The philosophy doc's own rules for the operator: start narrow, tune for less noise (shorter, stricter prompts, or pause it), do not use it to produce volume, and own what it says, because it posts under accounts your team sees every day.
06. Bug report to pull request
The loop you run every day
- Write the bug like you would for a teammate. Steps to reproduce, what you expected, what happened, and where you think it lives.
- Tag the agent on the issue from an account on the allowed list:
@<agent login> please fix this and open a pull request. SETUP.md says the work item shows up on the panel within about a minute. - It confirms once and goes quiet. It works in its own session and folder, on a branch starting with
agent/. - If it needs you, it asks one concrete question in the same thread. The panel shows the item as Awaiting answer. Reply in the thread and it continues.
- It comes back with a pull request. The panel shows Awaiting review. Read the diff, run the tests, and request changes in the pull request like you would with a person. A new message from you wakes it up again.
- You merge. Keep this manual until its pull requests have been right for a while.
If it gets blocked or fails, the docs say it reports that honestly instead of bypassing a limit, and the item shows as Blocked or Failed until a person writes in the thread.
For a team, this turns the "can someone look at this?" pile into a queue the agent picks up, while people only spend time on reviews and decisions. How much time it saves depends on your repo and your bugs, and DeepSeek's numbers are from early synthetic tests, so treat them as a direction, not a promise.
07. Where it goes wrong
- Treating it like a product. It is a research prototype. The README warns it may contain bugs and inconsistent code. Start on a test repo.
- Running it as yourself. Use a dedicated agent account and, ideally, a separate machine or OS user. Workers run commands without approval.
- A long allowed list on day one. More people asking means more pull requests to review and more noise. Grow it slowly.
- Turning on proactive work too early. Keep
observeuntil what it would have done looks right. - Re-running the profile command on upgrade. It replaces the profile and deletes its configuration. The doc's upgrade path is
git pull && pnpm install && pnpm build. - GitHub Enterprise Server. Not supported. It needs a github.com repo.
- Merging without reading. An agent pull request is a draft from a fast teammate, not a finished change.
- Skipping your own checks. Run the same review you would for any AI-written code. My vibe coding safety checklist and Red/Green TDD for AI coding agents guide cover what to look for.
08. Copyable prompts
1. A bug report it can act on
@<agent login> Bug: [one line]. Steps to reproduce: [1, 2, 3]. Expected: [...]. Actual: [...]. Probably in: [file or area]. Please reproduce it first, add a failing test, fix it, and open a pull request. Ask me before changing anything outside [area].2. A small, safe first task
@<agent login> Please fix the typo and broken link in README.md and open a pull request. Do not change any code.3. Review its pull request with your own coding agent
Review pull request #[number] in this repo from a fresh context. Check that the fix matches the issue, that there is a test that fails without it, and list anything risky or out of scope. Do not edit files, only report.4. A delivery rule for its prompts
Delivery requirements: open a pull request for every change, never push to main, keep each pull request to one issue, include how you tested it, and stop with one question if the fix needs a design decision.FAQ
What is the DeepSeek super agent?
It is dsh-superagent, a research prototype from DeepSeek's Harness team, released under the MIT license on 31 October 2026. It is a proactive coding agent for one GitHub repository, packaged as a bundle for DeepSeek Harness. When someone on an allowed list asks it for work, it opens a work item, works on it in its own session and folder, and answers in the same conversation, for example with a pull request.
Is it an official DeepSeek product?
No. The README says it is a research prototype for reference only, not an official DeepSeek product. It grew out of the team's day-to-day work, with much of the engineering done by coding agents, and it may still contain bugs.
What do I need to run it?
Node.js 22.19 or newer (or 24), pnpm, git 2.32 or newer, Python 3.8 or newer, tmux, the GitHub CLI 2.48 or newer, a repository on github.com, DeepSeek Harness with a model provider configured, and a separate GitHub user account for the agent with write access to the repository.
How do I set it up?
Clone the repository and ask your coding agent to read SETUP.md and set it up with you. It asks one question at a time, shows you the full plan once, and installs only after you confirm. Steps that need your hands, like creating the agent account and signing in, come as one message with the exact commands.
How do I give it a bug to fix?
From an account on the allowed list, comment @ followed by the agent's login and your request on an issue in the repository. The setup guide says a work item appears on the panel within about a minute. The agent confirms once, works quietly, and comes back in the same thread, for example with a pull request for you to review.
Will it merge code on its own?
Not by default. The setup recommends that people merge until the agent's pull requests have been right for a while, and the agent never enables auto-merge as its own account. If you allow auto-merge later, the default rules limit it to its own ready, approved pull requests under 200 changed lines.
How is it different from Copilot or Claude Code on GitHub?
Those can also turn an issue into a pull request. dsh-superagent is built to stay on all day for a whole repository and, optionally, a team chat, with one session that only routes work and a separate worker session and folder for each task, and it is designed to message people only when they must act or can use a result. It is also a self-hosted research prototype, so the setup is heavier.
Is it safe to run?
Treat it as research code. Its workers run commands without approval as your operating system user, and the docs say its folder limits are defaults, not a security boundary. Run it on a test repository and a separate machine or user account first, keep the allowed list short, keep proactive work in observe mode, and never give it production secrets.
What I checked, and what I did not
On 7 November 2026 I read the official README, SETUP.md and docs 000, 001, 002, 003, 005, 006 and 007, and checked the repo on the GitHub API: 20,216 stars, 2,350 forks, MIT, created 31 October, last push 3 November 2026. The router, watchdog and timing numbers come from DeepSeek's design essay as reported in news coverage and posts quoting it. I did not install or run it myself, so the setup steps are DeepSeek's, not a test of mine. It changes fast, so check the repo again before you install. Thanks to the DeepSeek Harness team for publishing it in the open.
Start narrow, let it pick up the bug reports, and spend your attention only on the reviews.
// Free newsletter
I send out guides like this every week
Real setups, real sources, no hype. Drop your email and I'll send you the next one.