All stories
dsh-superagent Ecosystem Community reports

DeepSeek's superagent prototype turns GitHub requests into background coding jobs

The MIT-licensed DeepSeek Harness bundle gives each authorized task its own session and directory, while warning that it is research code with full machine access.

Sources (5)

Why now The October 31 initial code release makes a concrete repository-level agent workflow inspectable, with English setup, authorization and deployment documentation.

DeepSeek’s harness team has published a coding-agent prototype built to take work from a GitHub conversation and return a result without someone supervising every chat turn. Released on October 31, dsh-superagent watches one repository, optionally listens to Feishu, and opens a separate ticket, agent session and directory for authorized work. A web panel shows what needs a person’s attention.

The team’s stated goal is to take as little human attention as possible while delivering useful work. Its English README says much of the engineering was done by coding agents during the team’s everyday development. It also explicitly calls the repository a research prototype for reference, not an official DeepSeek product or production-ready software. The published implementation differs from its internal version, and some designs discussed in the accompanying article are future directions.

A bundle around a model

This is a bundle installed into DeepSeek Harness, the application that hosts the sessions. It is not a new DeepSeek model. Operators still configure a model provider, and the prototype uses the profile’s default model unless evaluation or execution settings specify another. An MIT code license does not supply free inference or a fixed operating cost.

The deployment guide pins its example installation to DSH 0.2.1-rc.3, then builds the repository with pnpm and links it into a separate web profile. Prerequisites include Node.js 22.19 or later in the supported range, git, Python, tmux and GitHub CLI 2.48 or later. The documented shell and tmux setup should not be read as a tested native Windows installer.

Who can start work matters

The documented route requires a dedicated GitHub user account with repository write access and separate CLI credentials. A GitHub App cannot substitute for that account because the service reads its notifications. Allowed lists and policy rules decide which requests may become work. The default proactive mode is observe: inferred tasks are assessed and recorded without being executed, while explicit authorized requests can proceed.

Separate ticket directories are not a security sandbox. The deployment guide says both router and worker presets run with danger-full-access as the operator’s OS user; a worker can read the home directory and execute programs by path. The authors recommend a dedicated OS account for isolation. AITrending reviewed the English source and documentation without deploying the prototype or independently measuring its reliability.