Deploy dsh-superagent

Deploy dsh-superagent: GitHub, Feishu & Workers

Author
DeepSeekAgent.io Editorial Team
Published
Updated

dsh-superagent-prototype is the DeepSeek Harness team's public prototype for a proactive coding Agent. One deployment serves one GitHub repository. It can operate with GitHub alone or add Feishu as another Source. Deployment requires more than enabling a chat option: it needs a dedicated DSH Profile, an Agent identity, execution directories, authorization rules, and a long-running process.

This guide follows the official SETUP.md and deployment documentation. Start with one test repository and keep proactive acceptance in observation mode.

Prerequisites

The prototype documents Node.js 22.19+ or 24, pnpm, Git 2.32+, Python 3.8+, tmux, GitHub CLI 2.48+, and a DSH version within the engines.dsh range in package.json. DSH also needs a working model provider.

For a controlled trial, prepare:

  • a dedicated GitHub account for the Agent;
  • one test repository;
  • a dedicated OS user or isolated machine;
  • a separate DSH Profile and state directory;
  • for Feishu, a separate bot app and an explicit chat allowlist.

Do not default to the operator's own GitHub login. Comments, commits, and pull requests should carry a visible machine identity.

Step 1: clone and read the entry documents

The official setup flow asks a coding Agent to read the instructions, collect configuration choices, present a plan, and only then execute. Human operators should begin with the same documents:

SETUP.md
docs/000-philosophy.md
docs/001-domain.md
docs/002-authorization.md
docs/003-execution.md
docs/006-deployment.md

Authorization is not optional background reading. It defines which messages may become work and when the system may only observe a candidate.

Step 2: answer the nine deployment questions

The official setup groups its decisions into three areas.

Sources

  1. GitHub only, or GitHub plus Feishu;
  2. the owner/repository to serve;
  3. the dedicated GitHub Agent account;
  4. the Feishu chats to listen to, if enabled.

Policy

  1. GitHub users who may request work;
  2. Feishu users who may request work.

Execution

  1. the repository checkout used to prepare each Ticket directory;
  2. the commit author identity;
  3. whether pull requests may use auto-merge.

For the first deployment, choose GitHub only, one repository, a short allowed list, and no auto-merge.

Step 3: create a dedicated Profile

The official deployment guide recommends a separate Profile named superagent, isolated from the Profile used for interactive work. Separation keeps Router and Worker presets out of ordinary Sessions, allows independent restarts, and limits the scope of PATH and Git configuration changes.

The sample panel port is 3082. Keep the panel on localhost or a controlled network rather than exposing it directly to the public internet.

Step 4: configure the GitHub identity and Source

Sign a dedicated GitHub CLI wrapper into the Agent account and grant that account only the repository access it needs. Source configuration includes:

  • repository owner/name;
  • Agent login;
  • enabled state;
  • received issue, pull-request, comment, and CI scopes;
  • allowed users.

The Agent may need to read the repository, push branches, and open pull requests. Merge authority should remain a separate team decision. Without branch protection and reliable review rules, keep auto-merge disabled.

Step 5: configure Ticket directories

Each Ticket receives its own directory and Executor Session. A prepare command can create a worktree or clone from the configured repository.

The layout should ensure:

  • Tickets cannot overwrite one another;
  • branches can be traced to Ticket IDs;
  • directories and Git history survive restart;
  • Agent credentials do not reuse the operator's login;
  • private home directories are not the default workspace.

The prepare command runs when a Ticket directory is first created. Validate it with an empty test Ticket before accepting real work.

Step 6: begin in observe mode

The accept mode controls inferred proactive work:

  • off: inferred candidates are not admitted;
  • observe: decisions are recorded as “would accept” without creating work;
  • auto: matching candidates may create Tickets.

Review Decisions in observe: what matched, why it matched, whether it duplicated existing work, and how much noise it would produce. Enable automatic acceptance only for rules that behave predictably.

Step 7: optionally connect Feishu

The Feishu Source needs a bot application, event subscription, and explicit chat scope. Begin with mentions rather than every message. If a dedicated chat later needs proactive detection, expand only that receiving scope and control request authority through the admission table.

GitHub and Feishu identities are not automatically mapped to the same person. Cross-source identity relationships belong in explicit team rules.

Step 8: start and verify

After startup, inspect the official status command and panel, then run three tests:

  1. an allowed user mentions the Agent on a test issue and one Ticket appears;
  2. the Worker uses its own directory and branch, then opens a pull request;
  3. unauthorized users, ordinary chat, and bot messages are ignored or only observed according to Policy.

Also test restart, command failure, and a human follow-up on an ended Ticket. Tickets, subscriptions, directories, and pending inputs should recover without duplicating external actions.

Step 9: prepare for continuous operation

Before long-running use, add a dedicated OS account or equivalent isolation, branch protection, panel access control, resource budgets, logging, and a credential-revocation procedure. The project's philosophy is explicit: start narrow, tune for less noise, and own what the Agent says.

Related reading

References