Add DeepSeek Harness Interactive (dsh-acp-interactive)

[ClickPM]

Adds DeepSeek Harness Interactive (dsh-acp-interactive), a community-maintained, unofficial ACP adapter for DeepSeek Harness, published as deepseekharness-acp-interactive on npm.

• Distribution: npx — deepseekharness-acp-interactive@1.0.9 (no args; the default command is the ACP server; no separate CLI or source checkout is required)
• Auth: Terminal Auth — initialize returns deepseek-api-key as a terminal method (args: ["--setup"]) when the client declares clientCapabilities.auth.terminal or the validator's _meta["terminal-auth"], and as an agent-type method with the same instructions otherwise, so a client never receives an empty list. --setup stores DEEPSEEK_API_KEY through the Harness credential store without echoing it; session/new returns the ACP auth_required error while the key is not configured, so clients show the method before the first prompt; the method also carries Zed's legacy _meta["terminal-auth"] object so stable Zed launches the terminal task; a session/prompt on the DeepSeek route without a key is answered with auth_required as well
• Icon: 16x16 monochrome SVG using currentColor / none only
• Repository: https://github.com/ClickPM/dsh-acp-interactive (MIT, LICENSE)

It composes the published @deepseek-ai/dsh-* packages behind a reviewed editor profile. It is not affiliated with or endorsed by DeepSeek and is a different package, id, and repository from the other DeepSeek Harness submissions (#506, #509, #510) and from the upstream automation-only @deepseek-ai/dsh-acp; the id follows the -acp convention used for wrappers here and matches the executable and repository names.

Validation

Run with this repository's own scripts on the PR branch:

• uv run --with jsonschema .github/workflows/build_registry.py --dry-run → Added agent: dsh-acp-interactive v1.0.9
• python3 .github/workflows/verify_agents.py --auth-check --agent dsh-acp-interactive --clean → ✓ Success: Auth OK: deepseek-api-key(terminal); from a cold npm cache the handshake completes in about 20 s on a GitHub-hosted runner (linked below) and comfortably inside the validator's 120 s budget in a clean node:lts container

Public evidence:

• CI (Ubuntu / macOS / Windows × Node 22.19 / 24: npm ci, typecheck, tests, pack, packed-install launcher verification): https://github.com/ClickPM/dsh-acp-interactive/actions/runs/34313416901 (7/7 jobs green)
• The same build_registry.py --dry-run + verify_agents.py --auth-check run against the published 1.0.9 on a GitHub runner, from the project's own workflow: https://github.com/ClickPM/dsh-acp-interactive/actions/runs/34313956609 (Auth OK: deepseek-api-key(terminal))
• Release with the tarball and SHA-256; the npm tarball is the release asset: https://github.com/ClickPM/dsh-acp-interactive/releases/tag/v1.0.9
• Screenshots of real Zed usage on Windows: the agent panel, slash commands and selectors, the auth_required → Configure DeepSeek API key → terminal --setup flow, and a sandbox-denied write escalating to an ACP permission request (Allow once / Reject) with the resulting tool cards: https://github.com/ClickPM/dsh-acp-interactive#in-zed
• The entry in this PR is kept verbatim in the project repository as registry/agent.json and re-validated daily with the Registry's scripts

The workflow for this first-time contribution is waiting for approval (action_required).

🤖 Generated with Claude Code

[ClickPM]

I have updated the PR description to acknowledge the related DeepSeek Harness submissions (#506, #509, and especially the similarly editor-facing #510), document this implementation's package/composition boundary, and make its independent community-maintained status explicit. The first-time contributor workflow is currently waiting with action_required. When convenient, could a maintainer please approve the CI run and advise whether the Registry accepts multiple independently maintained ACP implementations built on the same upstream Harness runtime, or whether consolidation/another selection criterion is preferred? Thank you.

[ClickPM]

Rebased onto current main as a single commit (no merge commits) and rewrote the description with reproducible evidence: this repository's own build_registry.py --dry-run and verify_agents.py --auth-check pass against the published package (Auth OK: deepseek-api-key(terminal), 67 s from a cold npm cache), and the project now has public cross-platform CI plus a release carrying the exact npm tarball. Links are in the description.

@Rizzen @benbrandt — when you have a moment, could you approve the first-time-contributor workflow run? Happy to adjust anything.

[ClickPM]

Update: the entry now points at deepseekharness-acp-interactive@1.0.9, and the description reflects it.

Since the previous comment the authentication flow was reworked after testing in Zed and against an IntelliJ-style initialize (no terminal-auth flag):

• initialize always advertises one deepseek-api-key method: terminal type (plus the legacy _meta["terminal-auth"] object stable Zed acts on) when the client declares terminal auth, agent type with setup instructions otherwise.
• session/new and session/prompt on the DeepSeek route without a stored key answer with auth_required instead of failing at the first model request, so the client shows the auth action; the key written by --setup is picked up on the retry.

Evidence, all linked from the description: cross-platform CI (https://github.com/ClickPM/dsh-acp-interactive/actions/runs/34313416901), this repository's build_registry.py --dry-run + verify_agents.py --auth-check run on a GitHub runner against the published package (Auth OK: deepseek-api-key(terminal), https://github.com/ClickPM/dsh-acp-interactive/actions/runs/34313956609), Release v1.0.9 whose tarball sha1 equals npm dist.shasum (https://github.com/ClickPM/dsh-acp-interactive/releases/tag/v1.0.9), and screenshots of the flow in Zed (https://github.com/ClickPM/dsh-acp-interactive#in-zed).

No further changes planned on my side; happy to adjust anything.