DeepSeek Super Agent: How to Install dsh-superagent (Tested Steps)

DeepSeek super agent refers to deepseek-ai/dsh-superagent-prototype, the repository DeepSeek published on October 31, 2026. It is an agent that watches one GitHub repository, turns whitelisted requests into tickets, and works them in isolated directories. The README opens with the sentence that should govern everything you do with it: research prototype for reference only, not an official DeepSeek product.

What is DeepSeek super agent, and what is it not?

It is a bundle plugin for DeepSeek Harness, not a standalone program. Someone mentions the agent in a GitHub issue, the request becomes a ticket, a worker session does the work in its own checkout, and the result comes back to the original thread — usually as a pull request. A web panel sits beside it and shows only what needs a human.

Item	Measured value
Commits	One, 8c32a9d
Traction	17.1k stars, 1.8k forks
License / version	MIT; 0.1.0 with private: true (never published to npm)
Runtime dependencies	Two: proper-lockfile, zod
Codebase	111 source files, 15,587 lines, 59 test files, 9 docs, 15 prompt files

What it is not: an official product, a hosted service, or a general-purpose agent you point at any task. There is no support channel and no version commitment. The repository states plainly that coding style and engineering practice may be inconsistent, which is what a research artifact looks like from the inside.

What do you need installed before DeepSeek super agent runs?

The prerequisites DeepSeek super agent documents are Node 22.19+ or 24+, pnpm, git 2.32+, tmux, Python 3.8+, GitHub CLI 2.48+, and a DeepSeek Harness version inside the engines.dsh range.

Dependency	Required	Machine used for this test
Node.js	22.19+ or 24+	v22.23.1 ✅
pnpm	pinned at 11.7.0	10.33.4 ✅
git / tmux / Python	2.32+ / any / 3.8+	2.43.0 / 3.4 / 3.12.3 ✅
gh	2.48+	not installed ❌
dsh	^0.2.1-alpha.2	not installed ❌

The testing boundary matters here. This test covered installation, type checking, the test suite, and the build — results are in the section below. It did not cover the full runtime, because the machine had no gh, no dsh, and no target repository or agent account. Every command from this point on comes from the repository’s docs/006-deployment.md and SETUP.md, not from a first-hand run.

How do you install DeepSeek super agent?

The documented path is one block:

npm install -g @deepseek-ai/[email protected]
git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git dsh-superagent
cd dsh-superagent
pnpm install && pnpm build

The build takes under a minute and produces 11 files totalling 693 KB, with lib/index.js at 450 KB. Then create a dedicated profile and link the bundle into it:

dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"

The first of those two commands is destructive on an existing profile: it replaces the profile and deletes its cordis.patch.yml. Use it for a fresh install only. Running it during a DeepSeek super agent upgrade wipes your machine-specific settings. The separate profile exists because the plugin modifies process-level PATH and git configuration and needs independent restarts, which conflicts with a working profile.

Which settings must you edit by hand?

Copy the example and replace every placeholder:

cp examples/profile.cordis.patch.yml ~/.dsh/profiles/superagent/cordis.patch.yml

Only two values need attention:

- id: webserver
  config:
    host: 127.0.0.1
    port: 3082          # panel port
- id: dsh-superagent
  config:
    stateDir: /home/you/.dsh/state/superagent   # absolute path required

stateDir holds the SQLite database, lock files, command shims, the agent’s git configuration, and one working directory per ticket. Back up orchestrator.sqlite inside it before any DeepSeek super agent upgrade, and note that the path cannot be changed from the panel — only from this file. Config errors fail the start outright and name the offending key in the log. If you want the optional Feishu source, remove disabled: true from the dsh-superagent-feishu entry here.

Why does the agent need its own GitHub account?

Because every commit, comment, and review DeepSeek super agent produces carries that identity. The documentation is direct about it: a dedicated account, never the operator’s own. Create the account, grant it write access to the target repository, then put a CLI wrapper in front of it:

mkdir -p ~/.local/bin
cat > ~/.local/bin/gh-agent <<'EOF'
#!/bin/sh
GH_CONFIG_DIR="$HOME/.config/gh-agent" exec gh "$@"
EOF
chmod +x ~/.local/bin/gh-agent
gh-agent auth login
gh-agent api user --jq .login

The final command prints the login, and the plugin reads it the same way. The wrapper exists so the plugin can point gh at agent credentials while it strips GH_TOKEN and GITHUB_TOKEN from the environment and configures git never to prompt for credentials.

How do you start the service and configure the panel?

scripts/dsh-superagent start
scripts/dsh-superagent status

start runs dsh --profile superagent inside a tmux session named dsh-superagent and waits up to a minute for readiness. Logs land in .artifacts/. Open the URL the log prints and select Superagent on the left.

The status exit code carries meaning, and reading it wrong sends you restarting things that a restart cannot fix:

Code	Meaning	Restart helps?
0	Running normally	—
1	Stopped, duplicated, unreachable, or runtime error	Yes
2	Running, but a component reports an error	No
3	Running, waiting for setup	No

Four settings blocks have to be filled before DeepSeek super agent accepts any work. Sources takes the repository as owner/name and the agent CLI path. Policy is where you add who may assign work under On each Source — an empty list means no request ever becomes a ticket. Execution takes a directory root and a prepare command. Prompts sets commit authorship and whether auto-merge is allowed.

The prepare command creates one checkout per ticket. Only the path needs changing:

git -C /home/you/src/widgets fetch --no-tags \
  "https://github.com/$DSH_SUPERAGENT_GITHUB_REPOSITORY.git" \
  "${DSH_SUPERAGENT_GITHUB_PR_HEAD:-HEAD}:refs/dsh-superagent/$DSH_SUPERAGENT_TICKET" &&
git -C /home/you/src/widgets worktree add \
  -b "agent/$DSH_SUPERAGENT_NAME" \
  "$DSH_SUPERAGENT_DIR" "refs/dsh-superagent/$DSH_SUPERAGENT_TICKET"

Those variables are registered by the plugin and insertable from the panel: DSH_SUPERAGENT_DIR, DSH_SUPERAGENT_NAME, DSH_SUPERAGENT_TICKET, DSH_SUPERAGENT_GITHUB_REPOSITORY. None of them carry credentials.

How do you hand DeepSeek super agent the first job?

Comment on an issue from a whitelisted account and mention the agent’s login. Within one polling cycle — a minute by default — a ticket appears in Overview. The agent replies with an acknowledgement, works in its own directory, and returns to that issue when it has something worth reviewing.

One detail trips people up: new issues and new comments arrive on the next poll, but adding a mention by editing an existing issue body does not reach the agent. It has to be a new comment.

What did testing DeepSeek super agent actually show?

git clone --depth 1 https://github.com/deepseek-ai/dsh-superagent-prototype.git
pnpm install --frozen-lockfile   # 5.6s, exit 0
pnpm check                       # typecheck + test + build

Stage	Result
tsc --noEmit	✅ zero errors
vitest run	⚠️ 1196 passed, 1 failed (58 files passed, 1 failed), 96.69s
tsdown	✅ 11 files, 693.50 KB

The single failure is at tests/sources.spec.ts:1097, in the Feishu event consumer. The assertion expects a malformed JSON line to set the source’s health to error with “JSON” in the detail. What it gets instead:

state: "ready", detail: "Listening for bot events"

A bad message line does not mark the health state as failed. It sits in the Feishu event path, so a GitHub-only deployment is unaffected, but it confirms the research-prototype label in the least ambiguous way available: the project’s own suite is currently red.

The repository pins [email protected] through packageManager. Installation and the build both worked under 10.33.4, so the pin is not enforced at runtime. If you hit a lockfile error, align to the pinned version before debugging anything else.

What are the known problems and risks?

The isolation is documented as insufficient. Both agent presets run with danger-full-access as your operating-system user. A worker can execute any program by absolute path and read your home directory. The documentation describes the wrapper and directory as establishing defaults, not a security boundary. If that matters, give the agent its own system account holding only its own credentials.

Nothing stops a bad merge except configuration. The agent account cannot enable auto-merge by default, because GitHub attributes that action to whoever enabled it. Enabling it requires naming a separate merge CLI in the delivery requirements. The documentation recommends starting in observe mode, where the agent records what it would have done without doing it.

The upstream is a single commit. There is no release history to reason about and no deprecation policy. A rollback after an upgrade depends entirely on the backup you took of orchestrator.sqlite, because a database migrated by a newer version will not open in an older one.

Frequently asked questions

Is dsh-superagent an official DeepSeek product? No. The README states it is a research prototype for reference only. DeepSeek also published a paper, Exploring Super-agent Design, and the repository notes that parts of the paper’s design are not implemented in this prototype.

Is superagent.sh the same thing? No. Searching for DeepSeek super agent surfaces an unrelated security product at that domain. The repository is deepseek-ai/dsh-superagent-prototype and nothing else.

Why a separate GitHub account instead of my own? Two reasons: attribution and credential isolation. Every automated commit and comment should be traceable to the agent rather than mixed into a human’s history, and the wrapper keeps the agent’s credentials out of an environment where your own are already present.

Does it merge its own pull requests? Not by default, and the agent account is blocked from enabling auto-merge. If you configure a merge CLI, the documented conditions still apply: ready, under 200 changed lines, required approvals covering the head commit. Many deployments will simply have a person merge.

How do you upgrade it? Wait until no worker is running, back up stateDir/orchestrator.sqlite, run git pull && pnpm install && pnpm build, then scripts/dsh-superagent restart. The backup is the only rollback path.

Related

• DeepSeek V4.1-Flash local deployment — the model half of the same release cycle. Where dsh-superagent is a harness you run against a repository, V4.1-Flash is a model you serve; that page covers VRAM requirements, Ollama and vLLM paths, and quantization trade-offs.
• MOSS-Image in ComfyUI — an install walkthrough of the same shape on a much smaller target, useful if the per-ticket directory model here is unfamiliar and you want a lighter first setup.
• Opus 5.5 cost analysis — relevant once the agent runs continuously, because per-token pricing and per-task cost diverge in exactly the direction an always-on worker makes expensive.

Sources

• github.com/deepseek-ai/dsh-superagent-prototype — README, SETUP.md, package.json, and the nine numbered files under docs/, with deployment details from docs/006-deployment.md
• Local test run, November 4, 2026 — pnpm install --frozen-lockfile, pnpm check, and tsdown on commit 8c32a9d; the single failure is reproduced at tests/sources.spec.ts:1097
• Repository contents — 111 source files, 15,587 lines, 59 test files, 9 docs, 15 prompt files, counted from the working tree

---