DeepSeek Super-Agent Prototype: An Open PR Bot With Full

DeepSeek Super-Agent Prototype: An Open PR Bot With Full Access

DeepSeek put a new repo on GitHub on October 31. It's called dsh-superagent, and it's the DeepSeek Super-Agent prototype: a proactive coding agent that watches one GitHub repository and, optionally, Feishu chats. It picks up requests and answers in the same thread, often with a pull request. It's MIT-licensed and has about 6,700 stars.

Read the first line of the README before you get excited. It says: Research prototype for reference only, not an official DeepSeek product.

We went through the README and the deployment and design docs line by line. We haven't run it against a real codebase. The docs are blunt about what this thing can touch on your machine, and that's the part most write-ups skip.

What the DeepSeek Super-Agent Actually Does

Most coding agents wait for you to open a terminal. This one is a GitHub PR bot that sits on an account and listens.

Here's the loop, per the repo's docs:

It watches notifications. The agent reads its GitHub account's notifications and, optionally, Feishu chats through a self-built bot app.
It acts when allowed people ask. Requests from people on an allowed list get worked on. Unlisted people are ignored by default, though their messages on an active thread still reach the agent as context.
It works in separate sessions. Each job runs in its own session, then the agent replies in the original conversation. That reply can be a pull request, pushed from its own account. Auto-merge is off by default.
It flags what needs a human. A local web panel, served on 127.0.0.1 port 3082 by default, collects items that need a person.

It runs on DeepSeek Harness, or DSH, which its README calls an open-source agent harness developed by DeepSeek AI. DSH is still a developer preview with breaking changes expected. Super-Agent pins a release candidate: @deepseek-ai/dsh@0.2.1-rc.3.

Technical Breakdown: Model, Triggers and Permissions

It's not tied to a DeepSeek model. The deployment doc says it uses the profile's default model unless the Eval or Execution settings name another. That surprised us.

The worker prompt is a template: You are a coding agent powered by the {{model}} model. So you bring whatever provider your DSH profile uses.

It polls. Requests normally arrive through the agent account's notifications, checked within a polling interval (one minute by default). Expect up to a minute of lag.

Editing a mention into an existing issue body won't trigger it, so post a new comment.

It needs a real GitHub user, not a GitHub App. The docs say an App cannot be the agent, because dsh-superagent reads the account's notifications. You'll create a dedicated account and give it write access to the repository. GitHub Enterprise Server isn't supported.

Proactive work starts switched off: the default accept mode is observe. When the agent thinks it should take something on, it logs it as would accept and does nothing. Explicit requests from allowed people still work in every mode.

Permissions live on the host, not in the chat. Design doc 002 puts it plainly: The host enforces allowed lists, rules and Mandates. Messages, comments and quoted documents are inputs to a decision; they cannot change those permissions.

A Mandate is the repo's name for a per-ticket permission record. The agent re-checks it before resuming work.

The setup stack is long but ordinary: Node 22.19+, pnpm, git 2.32+, tmux, Python 3.8+ and gh 2.48+. Setup can run as an interview, with a coding agent reading SETUP.md, or you can follow docs/006-deployment.md by hand.

The Full-Access Problem: AI Coding Agent Security Nobody's Headlining

Here's the line from the deployment doc that matters most:

> Both presets run with danger-full-access as the operator's OS user… A worker can execute programs by path and read the operator's home directory. For isolation, use a dedicated OS account containing only the agent's credentials.

Read that twice. The account wrappers pick which credentials the agent uses. They don't sandbox the process.

Setup does help a bit. It strips environment variables whose names contain KEY, PASSWORD, SECRET or TOKEN, and it replaces the global git config so git only uses the agent's credentials.

But that filter matches names, not values. A variable called DB_PASS or DATABASE_URL slips through, because neither name contains one of those four words.

Credential files like ~/.aws/credentials, ~/.kube/config or your ~/.ssh keys aren't environment variables at all. They're just files in your home directory, which the worker can read.

Now connect two facts. Comments can't change the agent's permissions. But comments are still input to the model, and the docs list trust in the body and quotes of a request as an open question.

So the permission boundary holds, while the content flowing through it doesn't get the same guarantee. If an allowed teammate asks the agent to fix an issue that quotes a poisoned README, the model reads that text as a process that can read your home directory.

That's the realistic risk. Not some stranger hijacking the bot.

Real-World Use Cases

Studying how proactive agents should work. This is the honest best use. Allowed lists, Mandates, observe mode and re-checking permission before resuming make a solid reference design to borrow for your own always-on agent.

A sandboxed team bot on a side repo. Spin up a dedicated OS user and a dedicated GitHub account, and point it at one non-critical repo. Let teammates ask it for small fixes, and you'll see quickly whether ticket-to-PR flow suits your team.

Feishu-first teams. If your team already lives in Feishu, the chat integration is built in. GitHub and Feishu are the only sources the docs cover.

Running observe mode as a dry run. Leave proactive work in observe for a week. The would accept log shows what it would have grabbed without touching anything, which is a cheap trust test.

Hard Limitations and Flaws

It's a prototype, officially. No product, no support promise. The README also says much of the engineering was done by coding agents, so treat the code accordingly.

One commit, no releases. The whole repo landed as a single commit (6337fc8). You can't follow its history or pin a tagged version.

It runs on a release candidate. Super-Agent pins rc.3 while the Harness repo's latest tag is already dsh-v0.2.1-rc.5. Expect breakage when you upgrade.

Full access by default. Covered above. Without a separate OS account, your home directory is in scope.

Not all of the design is built. The README says some designs discussed in the article are directions for future development and are not implemented in this prototype. The article is Exploring Super-agent Design: Towards a More Autonomous Agent System, and the prototype doesn't say which designs are missing.

Minute-level latency, no GHES. Polling means it'll never feel instant. Enterprise Server shops are out entirely.

Verdict: Your Developer Action Plan

The DeepSeek Super-Agent prototype is worth an hour of your time, but as reading material first. The docs are unusually honest about AI coding agent security trade-offs, and the Mandate model is a good pattern to borrow.

If you want to run it, do it in this order:

Create a dedicated OS user that holds only the agent's credentials.
Create a dedicated GitHub user and give it write access to one test repo.
Keep accept mode on observe and keep the allowed list short.
Leave auto-merge off, and review every PR it opens like a stranger's.
Check the would accept log after a week before you widen anything.

Don't put it near production repos or a laptop with your real SSH keys. It's built to act on its own initiative. Right now, it does that with full access.