dsh-superagent: a GitHub coding agent prototype for DeepSeek Harness

dsh-superagent is a research prototype that runs as a plugin bundle for DeepSeek Harness (dsh). It watches one GitHub repository and can optionally receive Feishu requests. When an authorized person asks for work, it creates a ticket, starts an agent session in a separate work directory and can report back with a pull request. A local web panel shows which work needs human attention.

The project is published in the deepseek-ai GitHub organization, but its README explicitly says this prototype is not an official DeepSeek product and is not production-ready. Use it to study and test proactive-agent workflows in an isolated environment.

What dsh-superagent adds to DeepSeek Harness

DeepSeek Harness supplies the agent sessions, model routes and plugins. dsh-superagent adds the workflow around incoming requests: it watches GitHub (and optionally Feishu), checks whether a request is allowed, creates a ticket, assigns work to an executor and returns a result through the original source. Each ticket receives its own session and directory. This is useful for teams exploring an agent that can pick up repository tasks without someone manually opening every coding session.

The two projects answer different questions. Read this page when you specifically want a repository-watching coding prototype that turns approved requests into ticketed work. Harness can be useful without installing dsh-superagent; start with its official documentation when you need to configure the general agent environment.

Understand the access model before a trial

The dsh-superagent deployment guide requires a dedicated Harness profile, a GitHub account for the agent, and a model provider configured in Harness. Optional Feishu support adds its own bot setup. The documented host tools include Node.js 22 (22.19 or newer) or 24+, pnpm, Git 2.32+, Python 3.8+, tmux and GitHub CLI 2.48 or later. The GitHub integration does not support GitHub Enterprise Server according to the current guide.

dsh-superagent's permission defaults need particular care. Its router and worker presets run with danger-full-access as the operator's OS user. Account wrappers select the agent's GitHub credentials; they do not isolate the running process. The guide says a worker can execute programs and read the operator's home directory, and recommends a dedicated operating-system account for isolation. For an evaluation, use a disposable machine or isolated user, a test repository and an agent account with only the repository access it needs. Keep personal credentials and unrelated project files outside that account.

The installation guide currently documents a 0.2.1-rc.3 Harness bootstrap, while Harness has since published later release candidates. Check the prototype's engines.dsh compatibility range and current release notes before pairing versions. Its setup instructions also warn that creating an already-existing superagent profile replaces that profile and its machine configuration; follow the upgrade section for an existing installation.

Budget model calls and the always-on host

There is no published fixed price per ticket. dsh-superagent uses the model provider configured in its Harness profile; the work may involve evaluation/routing, executor turns, follow-ups and retries. Count the actual model calls and token usage for accepted tickets as well as work that fails or needs repair. If DeepSeek API is the configured provider, use the current DeepSeek API prices for the exact model and token categories. The DeepSeek-V4.1-Flash guide explains its model API and costs. A different provider has its own rates and limits.

Add the host cost separately. The dsh-superagent watcher and panel run on an operator-managed machine; include its reserved or rented time, storage, backups and any network or bot-service charges relevant to your setup. An agent that waits for work still occupies an operating environment. For a monthly estimate, add model spend for completed, failed and retried tickets to the host and service costs. To compare with manual work, divide by tickets accepted after review, not by every ticket the agent attempted.

The setup guide also describes hourly health checks and a repair process for a stopped agent. That adds operational work and may restart processes; it does not make the prototype a managed or always-available service. Start with low request volume and review its logs, outputs and credentials before expanding access.

Review the prototype's limits

Two contributors reported dsh-superagent edge cases against prototype commit 6337fc8 on November 1, 2026. In discussion #11774, Eric Cai reproduced missed GitHub stream items beyond the first page when more than 100 shared an update timestamp, using local mocked transport tests. In discussion #11801, he-yufeng described retry authorization, preparation cancellation and partial-directory reuse after a failed preparation; the thread includes local regression checks and a separate process check with a real provider. Neither thread reports a live end-to-end run across real model, GitHub and Feishu accounts or an accepted upstream fix as of this review. Check the current prototype revision and follow-up discussions before relying on those paths.

What operators have reported

On November 1, xxxxkkkqq reported an issue-to-PR run in a private repository after a fresh Ubuntu install with DSH 0.2.1-rc.5, Node 24.14.0 and GitHub CLI 2.103.3. The author also encountered mentions producing no tickets while the Source appeared ready. Adding notification scope and subscribing still left notifications empty; enabling observeIssues and observeComments provided a direct-repository fallback. The post does not identify which delivery path the successful request used. This is useful when diagnosing a watcher that appears healthy but receives no work.

Installation can also take operator time. A macOS user's agent-assisted report describes incompatible DSH versions, skipped native install scripts and multiple executable paths that complicated setup. Separately, Turquoise UFO reported checks/statuses HTTP 403 in a modified private deployment using a GitHub App. Its team distinguishes unavailable CI evidence from passing checks; its Telegram bridge is a custom extension. Check the installed versions and account permissions when comparing these reports with your own setup.

These reports reinforce the project's own guidance: inspect and adapt the code before using it. Avoid broad repository permissions and automatic merging during a trial. Keep a person responsible for reviewing the proposed patch and for deciding whether it should enter the main branch.

Inspect the source and follow the setup guide

The dsh-superagent prototype is MIT-licensed. Start by cloning the public repository to inspect the source:

git clone --depth 1 https://github.com/deepseek-ai/dsh-superagent-prototype.git dsh-superagent-review
cd dsh-superagent-review
git status --short

For installation, follow the official setup checklist and deployment guide in the isolated environment described above. The setup guide asks a coding agent to collect your choices and present a plan before executing it. Review that plan’s repository, account and model selection before starting the watcher.

Sources

Reviewed November 2, 2026. Sources include the prototype README, its setup, authorization model, execution model, deployment guide, Harness releases, and DeepSeek API prices. Community reports are discussion #11706, discussion #11714, discussion #11774, discussion #11801, and discussion #11818. For the general runtime, follow the DeepSeek Harness documentation.

For a game-testing workflow, compare Aura Autopilot. Browse the Agent guides on the home page for more options.