Autopilot — Turn approved work into review-ready pull requests with DeepSeek Harness.
Autopilot
Autopilot turns approved tracker work into bounded agent runs and review-ready pull requests inside DeepSeek Harness (DSH).
What problem it solves
Running a coding agent is easy. Operating one continuously is harder: somebody still has to decide which ticket is ready, track reported token use, limit concurrency, recover interrupted work, publish the exact verified commit and tell the team what happened.
Autopilot adds that operational layer to DSH. It keeps approval, review and merge with humans while automating the work between an approved ticket and a pull request.
It does not replace DSH or vendor integrations. DSH owns the agent runtime, Sessions, credentials and Web shell. Tracker and code-host access reuses official MCP servers and their existing authentication; Autopilot adds only the scheduling, lifecycle and publication behavior that joins them together.
What it does
- Admits only tickets carrying the configured ready marker and current human authorization.
- Queues work under schedule and concurrency limits, reserving a configured allowance against provider-reported token use.
- Runs the repository's own instructions in a managed Git worktree through DSH.
- Pauses, resumes and cancels without discarding durable run history.
- Recovers interrupted publication, notifications and retained worktrees after restart.
- Revalidates the exact Git state before creating a pull request.
- Shows queue, run details, worktrees, delivery status and settings in DSH Web.
- Stops at pull-request creation; humans still own review, CI decisions and merge.
The contributor test suite verifies the current alpha with controlled providers. Production provider promotion remains gated by provider conformance. Jira, GitHub Issues and GitHub code hosting are the first adapters; Linear, Bitbucket and later providers use the same provider contracts and MCP-first authentication policy.
The alpha budget fields reserve capacity and reconcile provider-reported usage after requests. They are not an exact cumulative pre-request hard cap; keep native execution disabled for metered production until the DSH budget boundary is completed.
How it works
flowchart LR
ticket["Approved ticket"] --> gate["Ready marker + authorization"]
gate --> queue["Schedule + capacity + budget"]
queue --> dsh["DSH agent in managed worktree"]
dsh --> verify["Checks + exact Git state"]
verify --> pr["Review-ready pull request"]
pr -.-> notify["Notification"]
If the agent needs a decision, Autopilot posts the blocker back to the tracker and waits for an explicit response. A paused run retains its Session and worktree for a checked resume. A cancelled queued or quiescent run stops cleanly while retaining the evidence needed to understand what happened.
Provider failures are isolated from the durable run result. For example, a notification outage cannot undo a completed pull request, and a restart can retry an uncertain publication without creating a duplicate.
Install
Requires an existing DSH installation.
dsh plugin --profile web add @canhta/dsh-autopilot@alpha
dsh --profile web
Open the URL printed by DSH, then select Autopilot in the sidebar.
Don't have DSH installed?
Install its CLI with npm, then run DSH Web once to finish the normal DSH setup:
npm install --global @deepseek-ai/dsh
dsh web
See the DSH repository for its own installation and safety guidance. Autopilot does not manage or upgrade this installation.
Configure
Open Settings → Autopilot to set the tracker and code-host bindings, schedule, concurrency, budget, notifications and retention policy. Configure the ready marker and provider-specific resource mapping in that provider's linked Settings section.
Fresh installs keep execution disabled. Before enabling it, select the DSH default Agent preset and model, then configure each provider's DSH Settings namespace and official MCP server in the same profile. Keep vendor OAuth, model keys and tokens in DSH Credentials; Autopilot does not create a second authentication flow.
Connect the GitHub and Jira MCP servers
Autopilot's providers call the vendor's official MCP server through DSH's dsh-mcp-client plugin, not a third-party clone. Add one entry per server to the profile's patch layer ($DSH_HOME/profiles/<profile>/cordis.patch.yml), then restart the profile (dsh --profile web).
GitHub — the official remote server needs no local install or Docker:
- insert:
- id: mcp-github
name: '@deepseek-ai/dsh-mcp-client'
config:
serverName: github
transport: streamable-http
url: https://api.githubcopilot.com/mcp/
headers:
Authorization: !!js '`Bearer ${process.env.GITHUB_TOKEN}`'
Create a token at github.com/settings/personal-access-tokens/new with Contents, Issues and Pull requests read/write, then set GITHUB_TOKEN in your environment before starting DSH.
Jira — the Jira provider's MCP contracts target Atlassian's official Rovo MCP Server, not a community Jira MCP server. serverName must be atlassian (the provider's default):
- insert:
- id: mcp-jira
name: '@deepseek-ai/dsh-mcp-client'
config:
serverName: atlassian
transport: streamable-http
# tools=all: Rovo only advertises a "primary" tool subset by default and expects
# on-demand discovery, which dsh-mcp-client's one-time tools/list bridge doesn't do.
url: https://mcp.atlassian.com/v2/mcp?tools=all
headers:
Authorization: !!js >-
`Basic ${Buffer.from(`${process.env.JIRA_EMAIL}:${process.env.JIRA_API_TOKEN}`).toString('base64')}`
Create an API token at id.atlassian.com/manage-profile/security/api-tokens, then set JIRA_EMAIL (your Atlassian login) and JIRA_API_TOKEN. An org admin must also enable API token authentication for the Rovo MCP Server (Atlassian Administration → Rovo → Rovo MCP server → Authentication) — OAuth-only organizations can't use this Basic-auth header form and need a different client integration.
Once connected, each provider's Settings card in Autopilot reports a live lookup status instead of a placeholder — a real, cached probe against that provider's declared MCP tools, not a static message.
For a systemd-managed VPS installation and backup/restore procedure, see One-VPS operation.
Contribute
Start with a GitHub issue so the problem and acceptance criteria are clear. Then run the repository checks before opening a focused pull request:
git clone https://github.com/canhta/dsh-autopilot.git
cd dsh-autopilot
pnpm install
pnpm run check
The full contribution workflow, verification expectations and package checks are in Contributing.
