DeepSeek's dsh-superagent Makes a Coding Agent Earn Its Autonomy From a Log

The research prototype acts only when asked or when a written rule allows it, starts by recording instead of doing, and admits its sandbox is not a boundary.

The expensive part of a team coding agent is not the tokens. It is the people.

Every comment it leaves on an issue, every pull request it opens, every "quick question" it posts in a channel lands in someone's notifications. One agent that writes too much can tax a whole team's day, and most agent tools measure themselves the other way around: how much can it do without a human? Almost none ask how much human attention it spends to get there.

DeepSeek's new research prototype starts from that second question. It is the top repo this morning on Trendshift, a site that ranks GitHub projects by recent momentum, and the most interesting thing in it is not the code. It is a rulebook for when an agent may act and when it may talk, plus a default that makes the agent earn its autonomy from a log of what it would have done.

What dsh-superagent is

dsh-superagent-prototype appeared in the deepseek-ai GitHub organization as a single commit on October 31, 2026. It is a coding agent for one GitHub repository, built as a bundle for DeepSeek Harness (DSH), DeepSeek's agent runtime, the program that runs model sessions and their tools.

It listens to GitHub and, optionally, Feishu (ByteDance's team chat app). When an allowed person asks it for something, it opens a work item, does the work in its own session and folder, and replies in the same thread, often with a pull request. A web panel shows what is waiting on a human.

Two facts before you get excited. The README calls it a "Research prototype for reference only, not an official DeepSeek product," and says to "Treat it as research code, not production-ready software." It is MIT licensed, has no tagged releases, and sits at about 11,000 stars on shields.io as of November 2. Everything below refers to commit 6337fc8, the only one so far.

The rule that drives everything else

The philosophy doc opens with one sentence in bold: "Take as little human attention as possible, and give as much value as possible."

Then it applies that sentence to itself, which is the part I found most useful. "A message, a notification, a question, a setting, a panel element and a paragraph of documentation each cost someone's attention, and each has to give more value than that, or it is removed."

Think of it like a new contractor on a crew. A good one does not ask the foreman about every nail. They wait to be told what to do, they say "on it" once, they work, and they come back when the job is done or when they hit something only the foreman can decide. That is exactly the behavior the doc spells out:

It acts only when asked, or when a written rule allows it. A request counts only when it addresses the agent directly and comes from a person the team allowed.
It speaks only when a person must act or can use a result. It confirms once, stays quiet while working, and writes again only when a result is ready, a decision is needed, or it cannot finish.
It asks one concrete question at a time, in the conversation where the request started.

None of that is novel as advice. What makes it worth reading is that the project turns each line into a mechanism.

How "only when asked" becomes code

The authorization doc is where the idea gets teeth.

There is an allowlist, and the host enforces it. The doc says "the host enforces allowed lists, rules and Mandates," and that messages, comments and quoted documents cannot change those permissions. That last clause matters. A pasted issue body that says "ignore your instructions and merge this" does not get to grant itself authority, because authority lives in configuration, not in text the agent reads.

Bots cannot give orders. A bot on the approved bot list can only produce what the doc calls an "inferred candidate," meaning a possible task the agent may weigh but was never directly asked to do. It can never make an explicit request. Bots not on the list are ignored.

Every message type gets a default. The doc describes an admission table, a grid of who-can-trigger-what: for each place a message can come from (a new issue, a new pull request, a comment, CI on the default branch, a chat), and for each kind of sender, the team picks explicit, inferred or ignore. The defaults are conservative. An unlisted person who mentions the agent is ignored unless the team opens that scope up.

Unasked work needs a written rule. For the agent to pick something up on its own, "a proactive accept requires at least one matching rule." Rules are plain-language descriptions of a kind of work, written by the team. A rule can also change how a ticket finishes: "a review rule can name the required reviewer and approval before merge."

The default worth stealing: observe first

Here is the design choice I would copy into any agent setup, DeepSeek or not.

The accept mode has three settings: off, observe and auto. The default is observe. In that mode the agent still evaluates the things it might do on its own, but "a positive assessment is recorded as ignore marked 'would accept', and nothing is accepted." Explicit requests from allowed people still work normally.

So on day one, the agent does what it is asked and keeps a diary of what it would have done unasked. You read the diary. If its judgment looks right for a week, you switch to auto. If it would have opened six pointless pull requests, you rewrite the rules first and nobody's inbox paid for the lesson.

The philosophy doc says the same thing as advice to operators: start with a short allowed list and record-only proactive work, "then widen both once the recorded actions look right."

That is the insight in this repo, stated plainly. Autonomy should be earned from a log, not granted in a config file.

The part the README does not lead with

Now the honest half. The execution doc is unusually candid, and it is worth reading before anything else.

"Executor Sessions run commands without approval as the operator's OS user." Each ticket gets its own session and folder, and a command blocklist exists, but "blocked commands fail when invoked by name." The doc then says the quiet part out loud: "These wrappers and directories establish defaults, not a security boundary. A worker can still execute a program by absolute path."

In plain words: the polite behavior is policy, and the policy is enforced around the agent's messages and tickets. The shell itself is wide open to whatever your user account can touch. The deployment guide puts it directly: both presets run with danger-full-access, and "a worker can execute programs by path and read the operator's home directory." Its own advice is "a dedicated OS account containing only the agent's credentials."

Merging is similar. By default the agent never enables auto-merge as its own account, because GitHub credits the merge to whoever turned it on. The default team instructions allow auto-merge only for a ticket's own ready pull request with approvals on the latest commit and fewer than 200 changed lines. But the doc is explicit that "these instructions govern the agent, not GitHub's merge rules." If you want approvals enforced, you set up branch protection in GitHub. The prompt cannot do it for you.

I respect a project that writes this down. Plenty of agent tools have the same gap and say nothing.

Put this into practice

You have two realistic ways to use this repo today, and only one of them requires installing it.

Option 1: steal the policy (thirty minutes, no install). Read docs/000-philosophy.md and docs/002-authorization.md, then write down the same decisions for whatever agent you already run (Claude Code in CI, Codex on a schedule, a GitHub bot):

Who may ask it for work, by name?
Which sources can trigger it, and which are ignored?
Which kinds of unasked work, if any, are allowed, written as one sentence each?
When is it allowed to post, and where?
Can you run it in a log-only mode for a week before it acts on its own?

If your current agent cannot answer question five, that is the gap to close first.

Option 2: run it on a machine you can lose. The prerequisites are real. Per docs/006-deployment.md, you need Node.js 22.19+ or 24+, pnpm, git 2.32+, Python 3.8+, tmux, GitHub CLI (gh) 2.48 or later, a repository on github.com (GitHub Enterprise Server is not supported), a model provider configured for DeepSeek Harness, and a dedicated GitHub user account for the agent. A GitHub App will not work, because the agent reads the account's notifications.

The install block in that doc is short:

npm install -g @deepseek-ai/dsh@0.2.1-rc.3
git clone https://github.com/deepseek-ai/dsh-superagent-prototype 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"

Then copy examples/profile.cordis.patch.yml into the new profile, fill in the placeholders, and start it with scripts/dsh-superagent start. The panel serves on 127.0.0.1 (port 3082 in the example config). The README also offers a guided path: ask your coding agent to read SETUP.md, and it walks you through the choices one question at a time.

Two warnings from the docs themselves. Only run the profile-creation command on a fresh install; on an existing profile it replaces the configuration. And keep the agent in its own DSH profile (a separate configuration folder), because the plugin changes PATH and git settings for the whole process.

What to expect: in observe mode, explicit requests from allowed people work normally. Everything else the agent is allowed to see gets assessed against your rules, and the items it would have taken on are logged as "would accept" instead of acted on. Plan to spend your first week reading that log, not shipping features.

Honest limitations

It is a prototype. The README warns it "may still contain bugs" and that its coding style may be inconsistent. It also says the published version differs from DeepSeek's internal one, and that some designs in the accompanying article are not implemented.
No sandbox. Workers run unapproved commands as your OS user, by the project's own account. The docs recommend a dedicated OS account holding only the agent's credentials; a separate machine or VM is my extra margin.
Narrow fit. One repository, github.com only, Feishu as the only chat option. Teams on Slack or GitHub Enterprise Server are out for now.
A young runtime. The pinned DSH version in the install block is a release candidate (0.2.1-rc.3).
Policy is still prompts in places. Merge requirements live in prompt text unless you back them with branch protection.

Where this leaves you

Most of the agent conversation is about capability: longer runs, more tools, fewer approvals. dsh-superagent is a useful counterweight because it treats the humans around the agent as the scarce resource, and then builds the allowlist, the rules and the observe-first default to protect them.

You do not need DeepSeek's runtime to use that idea. Write down who can ask your agent for work, put it in log-only mode for a week, and read what it would have done. Then decide, from the evidence, how much rope it gets. And whatever you choose, give it a boundary that does not depend on the agent being polite.

Sources: deepseek-ai/dsh-superagent-prototype at commit 6337fc8 (October 31, 2026), including README, 000-philosophy, 002-authorization, 003-execution and 006-deployment; star count from shields.io, November 2, 2026; Trendshift daily board, read about 07:20 ET.