DeepSeek’s coding-agent prototype puts permission before initiative

A coding agent that can read a team’s conversations faces a problem before it writes any code: which messages are instructions, and which are merely information? DeepSeek’s new research prototype makes that distinction a central part of its design.

The public dsh-superagent repository records its initial commit on October 31, 2026. Packaged for DeepSeek Harness, it watches one GitHub repository and can optionally receive messages through Feishu. An accepted request becomes a work item with its own agent session and directory; a result can return to the original conversation as a pull request.

This is not a new production service. The README calls it research code, warns of bugs and inconsistent engineering practices, and says it differs from the team’s internal version. Some ideas in the accompanying design discussion are future directions rather than implemented features.

Reading a message does not grant permission

The authorization document separates the decision to start work from the delivery of context to existing work. A permitted person directly addressing the agent can make an explicit request. Subscribed discussion threads can supply further messages, including bot and continuous-integration output, without granting new authority.

The host enforces permission lists, rules and the scope of an accepted task. Comments and quoted documents cannot change those permissions. That is a stated control in the design, not evidence that every adversarial input will be handled correctly.

Proactive work has three modes. The default, observe, records favorable assessments as work the agent would have accepted without actually accepting it. Auto can accept inferred work when an enabled rule matches; off excludes inferred candidates while leaving explicit requests available. Teams can inspect proposed behavior before enabling it.

The worker still inherits real access

Once work is accepted, the execution documentation describes a worker session and a separate directory for that task. A preparation command can create a Git worktree, allowing changes to be developed in their own checkout.

The same document states that workers run commands without approval as the operator’s operating-system user. It explicitly says the command wrappers and directories establish defaults rather than a security boundary. A separate work directory should therefore not be mistaken for a sandbox that prevents access elsewhere.

Merging has another boundary. The host has no merge-specific decision logic; delivery instructions govern the agent’s behavior. The documentation directs operators to GitHub branch protection when they need approvals enforced. A prompt describing an approval requirement and a repository rule enforcing one do different jobs.

UpThat has reviewed the public documentation, not installed or independently tested the prototype. These are descriptions of its published design and operating assumptions, not a security audit or a measured productivity result.

Human attention is part of the operating budget

The project’s philosophy asks the agent to communicate when a person needs to decide something or can use a result. Its panel prioritizes work waiting for human attention. The operator is told to start with a narrow permission list, observe proactive behavior and avoid generating mass pull requests or broadcast messages.

That is a useful way to evaluate repository agents. Producing another patch is not automatically a contribution if the team must spend more time discovering why it exists, checking whether it was requested and deciding who owns it. This is an operational implication of the design, not a saving the project has demonstrated.

For teams studying the code, the first review should follow authority from end to end: who can initiate work, what an accepted task permits, which machine account executes it, and what enforces review before merging. The prototype exposes those questions clearly. Answering them still belongs to the people deploying it.