Field SOP
Field SOP

Hands-on SOP: One npx Line to Run DeepSeek Harness - Install, Four Modes, Trajectory Replay, and Your First Plugin

A DeepSeek Harness quickstart SOP: environment prep -> one-line launch via npx @deepseek-ai/dsh web (127.0.0.1:3080) -> mode-selection mnemonic (work in Standard / orchestrate in Code / test models in Minimal / write plugins in Creator) -> trajectory replay & fork for debugging -> your first dsh-plugin. 5 pitfalls: no production on v0.1 / audit plugins first / budget tokens (peak-hour price hike) / two network chokepoints / spartan UI is by design. Per the official repo.

Published August 15, 20267 min read
<!-- deepseek-harness-quickstart-sop | sop | Hands-on SOP: One npx Line to Run DeepSeek Harness - Install, Four Modes, Trajectory Replay, and Your First Plugin -->

DeepSeek Harness (dsh) hit 100K stars in two days, but "developer preview + plugin architecture" means a wrong approach wastes hours. This SOP lays out the shortest path from zero: environment prep -> one-line launch -> mode selection -> trajectory replay -> first plugin -> cost control, plus 5 pitfalls. News background in the Harness hotspot; tool selection in the Agent Harness comparison.

Boundaries: steps assembled from the official README and launch docs (as of 2026-08-15); v0.1 iterates fast - commands and UI per the official repo; this is a curated guide from official docs and public tutorials, not a keystroke-by-keystroke log.

Step 1: Environment Prep (10 minutes)

dsh is a Node.js project; prerequisites are just two things:

sh
# 1. Node.js (LTS recommended; confirm with node -v)
node -v

# 2. A DeepSeek platform API key (for the model plugin; other providers' keys work too)
#    Export as an environment variable; the UI guides you on first launch

Two pre-checks: ensure npm registry reachability (switch to a mirror if needed) and model API endpoint connectivity; source-based installs additionally need pnpm.

Step 2: One-Line Launch (2 minutes)

sh
npx @deepseek-ai/dsh web

The Web UI opens by default at http://127.0.0.1:3080. On first launch, configure the model plugin per the UI prompts (API key, model choice), then start your first session. From source:

sh
git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

Note the Web UI is a local service (127.0.0.1); opening it in a browser is its designed form, not an unfinished product - the community gripes about the spartan look, but the features are all there.

Step 3: Pick a Mode per Task (5 minutes to learn, benefits for life)

ModeTool surfaceWhen to use
StandardFull set: file edit, shell, file/web search, skills, planning, sub-agentsDefault for daily dev tasks
Code (PTC)All of Standard + Code Mode SDKComplex tasks where the model composes many tools in one TypeScript program
MinimalPersistent bash + str_replace_editor onlyEvaluating raw model capability; the official Code Agent benchmark environment
CreatorRuntime inspection + plugin experimentsDeveloping/debugging your own plugins and presets

Mnemonic: work in Standard, orchestrate in Code, test models in Minimal, write plugins in Creator.

Step 4: Use Trajectories to Debug a Runaway Agent

dsh writes system prompts, chain of thought, tool calls and results, sub-agent dispatch, and every context injection to an append-only session log. In the trajectory view you can filter by source and resume, fork, search, and replay any run. Three practical uses:

  1. Wrong result -> replay the trajectory to locate which tool call introduced the drift, instead of rerunning on luck
  2. Want to try a different path -> fork from a node and compare both paths on cost and outcome
  3. Prompt review -> check whether the system prompt and context injections took effect as intended

Step 5: Your First Plugin

Plugins are dsh's core extension mechanism; the official route: tag your plugin repo with the dsh-plugin topic for discoverability (~300 plugins in the ecosystem so far). Development flow: inspect the live runtime in Creator mode, experiment with Cordis plugin combinations, then solidify the winners into your own preset mode. Make your first plugin minimally useful: wrap one internal tool you use daily (a query, a deploy, a notification). Don't start by rewriting the loop or orchestration.

Five Pitfalls (Read Before Doing)

  1. Don't weld production onto v0.1: the official warning of compatibility-breaking changes is explicit; core plugins and APIs keep moving. Production waits for a stable release; today's positioning is experiments and learning.
  2. Audit third-party plugins before installing: ~300 community plugins with no review mechanism - read the source, run in a sandbox, never hand model credentials to an unknown plugin.
  3. Budget before you run: the companion V4-Pro-0813 is strong but metered, and DeepSeek raised peak-hour prices (V4-Flash output ¥2->¥9/M). Multi-tool long tasks amplify token burn linearly - price it on small tasks first.
  4. Two network chokepoints: npm package pulls and model API connectivity - either failing stalls startup; test both before debugging anything else.
  5. The spartan UI is not a bug: a local Web UI in the browser (127.0.0.1:3080) is the designed form; don't wait for a "native app." For a mature terminal experience today, see the Agent Harness comparison.

FAQ

Q1: What's the minimum environment for DeepSeek Harness? A1: Node.js (LTS recommended) + one model API key (DeepSeek or another provider). The fastest path is npx @deepseek-ai/dsh web with no cloning; source installs additionally need pnpm for pnpm install && pnpm run build && pnpm dsh web.

Q2: How do I choose among the four run modes? A2: Mnemonic: "work in Standard, orchestrate in Code, test models in Minimal, write plugins in Creator." Standard is the full-toolset daily default; Code (PTC) uses the Code Mode SDK to compose multi-tool operations in a single TypeScript program; Minimal keeps only bash + file editing - the official benchmark environment; Creator experiments with plugins at runtime to build new presets.

Q3: The Web UI opens as a browser page - did the install fail? A3: No, it succeeded. dsh's interface is a local Web UI; after npx @deepseek-ai/dsh web it serves at http://127.0.0.1:3080 by default, and browser access is by design. The community gripes about the look, but sessions, trajectories, and plugin management all live in that UI.

Q4: How is the trajectory feature actually used? A4: Every run's events (system prompts, chain of thought, tool calls and results, sub-agent dispatch, context injections) go into one append-only log; the trajectory view filters by source and supports resume, fork, search, and replay. Typical flow: replay to locate the drifting tool call on a wrong result; fork mid-run to compare paths; audit prompt injections.

Q5: Is it worth migrating daily development to dsh now? A5: Not yet. v0.1 is a developer preview with official breaking-change warnings, unreviewed plugins, and a builder-oriented experience. The sensible posture today: work in Claude Code/OpenCode (see our DeepSeek × Claude Code SOP for the cost-saving DeepSeek setup) and treat dsh as a learning and experiment platform until its API stabilizes.


References

  • GitHub: deepseek-ai/deepseek-harness README (install commands, port, developer-preview warning, dsh-plugin topic, Discord)
  • DeepSeek official launch docs: four run modes, append-only trajectory, Cordis plugin architecture
  • NetEase Tech (2026-08-13): install methods and the four modes
  • Zhihu hands-on posts (2026-08-14): npx @deepseek-ai/dsh web launch experience and UI form
  • EastMoney/Sina Finance (2026-08-14): V4-Flash peak-hour price hike (output ¥2->¥9/M)

Curated from official docs and public tutorials (2026-08-15), not a step-by-step log; commands and UI per the official repo. Related: Harness hotspot | Agent Harness comparison | DeepSeek × Claude Code SOP

This article is AI-assisted and human-edited. Last updated: 2026-08-15

FAQ

What's the minimum environment for DeepSeek Harness?
Node.js (LTS recommended) + one model API key (DeepSeek or another provider). The fastest path is `npx @deepseek-ai/dsh web` with no cloning; source installs additionally need pnpm for `pnpm install && pnpm run build && pnpm dsh web`.
How do I choose among the four run modes?
Mnemonic: "work in Standard, orchestrate in Code, test models in Minimal, write plugins in Creator." Standard is the full-toolset daily default; Code (PTC) uses the Code Mode SDK to compose multi-tool operations in a single TypeScript program; Minimal keeps only bash + file editing - the official benchmark environment; Creator experiments with plugins at runtime to build new presets.
The Web UI opens as a browser page - did the install fail?
No, it succeeded. dsh's interface is a local Web UI; after `npx @deepseek-ai/dsh web` it serves at http://127.0.0.1:3080 by default, and browser access is by design. The community gripes about the look, but sessions, trajectories, and plugin management all live in that UI.
How is the trajectory feature actually used?
Every run's events (system prompts, chain of thought, tool calls and results, sub-agent dispatch, context injections) go into one append-only log; the trajectory view filters by source and supports resume, fork, search, and replay. Typical flow: replay to locate the drifting tool call on a wrong result; fork mid-run to compare paths; audit prompt injections.
Is it worth migrating daily development to dsh now?
Not yet. v0.1 is a developer preview with official breaking-change warnings, unreviewed plugins, and a builder-oriented experience. The sensible posture today: work in Claude Code/OpenCode (see our [DeepSeek × Claude Code SOP](/en/deepseek-v4-pro-claude-code-sop) for the cost-saving DeepSeek setup) and treat dsh as a learning and experiment platform until its API stabilizes.

Related

Field SOP

Build Long-Running Agent Workflows with GPT-6 Astra

A hands-on SOP for building long-running agent workflows on GPT-6 Astra's real capabilities (1.05M context, 128K output, 0% alignment overreach): start with three prerequisites (OpenAI Python SDK 1.50+, the OPENAI_API_KEY environment variable, and API allowlist), then proceed in order through long-context planning, tool definition (function calling plus computer use), async invocation, mid-flight correction, and acceptance with cost control. Key points: on the first call place only the goal, acceptance criteria, tool list, and key background so the model emits a plan first; tools must specify name, description, and parameters; use streaming events plus a background queue and task-id polling for async; correct course by injecting new instructions without restart; and accept only via independent assertion scripts while keeping max_output_tokens small and setting a daily spend cap.

Sep 4, 202611 min read
Field SOP

Back up the state directory before you upgrade: OpenClaw 2.0 migration, rollback and credential-hardening SOP

For engineers already running OpenClaw: how to get up to 2.0 safely, how to roll back if it fails, and how to tighten credentials afterward. First principle — before upgrading, back up the Gateway's entire configuration and state (not a single client) and verify it is recoverable. Four upgrade steps: check → openclaw doctor --fix → restart the Gateway → verify health (model-access verification must pass for the upgrade to count). Two breaking changes: the OpenProse plugin and /prose command removed (.prose source files are preserved), and codex/* plus openai-codex/* routes move to openai/* (conflicts fixed manually). The 2026-09-01 plugin SDK deprecation (plugin-sdk-config-runtime-subpath → api.pluginConfig) is due today. Rollback is bounded: sessions created after the move to SQLite are invisible to the old version, and a full rollback also takes approvals and dedup records back. After upgrade, actively enable five things: masked credential requests, the proxy allowlist, precise authorization, role narrowing, and correcting the Incognito misconception.

Sep 1, 202614 min read
Field SOP

Migration SOP for Model Sunsets and Repricing: Four Steps to Inventory, Migrate, Recalculate, and Contain Cost

Three things happened at once on 2026-08-31: Sonnet 5 API rates moved from $2 and $10 to $3 and $15, GPT-5.4 and GPT-5.4 mini stopped being offered to Codex users signed in with ChatGPT, and kimi-k2.5 and moonshot-v1 sunset the same day. The three change types need completely different responses, yet most teams apply one uniform reaction and end up either overreacting or underreacting. This SOP runs four steps. Step zero classifies using keywords in the vendor announcement: sunset or deprecated means the ID stops responding, handle it today; replace or a default change means the entry point still works but the model behind it changed, so run a regression this week; pricing only means no interruption but a recalculation this month. Step one inventories every model ID in the codebase with a single grep, collapses them into one central config, and wires the check into CI. Step two executes the per-type migration. Step three recalculates monthly cost from three factors: tokenizer inflation, peak versus off-peak share, and cache hit rate. Also included: an eleven-item checklist, step four on limits, alerts and a fallback path, and seven ways this goes wrong, the most common being model IDs scattered through code where one fix misses three call sites.

Aug 31, 202612 min read