Choose native PowerShell or WSL2 first

Use native PowerShell when your repositories, Node installation, browser, and daily shell already live on Windows. Use WSL2 when the repository and its dependencies already run inside Linux. Mixing a Windows Node process with a WSL workspace creates path, permission, and executable-resolution problems that look like DSH failures.

  • Keep the DSH process and workspace in the same environment.
  • Open the Web UI from the host browser only after the process reports its listening address.
  • Do not treat a community one-click package as official unless DeepSeek links to it.

Native PowerShell path

Confirm Node and npm in the same PowerShell session, then launch the official package. Native Windows startup is directly verified on the recorded matrix below, but the current npm metadata does not declare a minimum Node engine.

PowerShell quick start · powershell
node --version
npm --version
npx @deepseek-ai/dsh web

Retained native Windows baseline

Test record HB-DSH-WIN-20260818-01 used Windows 11 Home China 10.0.26200 x64, PowerShell 7.6.4, Node v24.11.1, npm 11.5.2, and an isolated DSH_HOME. DSH rc.6 started in 3.491 seconds, upgraded to rc.7 in 3.445 seconds, rolled back to rc.6 in 3.463 seconds, and cleanly reinstalled rc.7 in 3.431 seconds. Every recorded state returned HTTP 200; the rc.7 and rollback UI checks loaded normally with zero browser-console errors.

  • Warm-cache process-tree working set ranged from 357.1 to 373.7 MiB.
  • A reversible profile removal closed the test ports; the shared npm cache was deliberately retained.
  • A separate cache-fill observation took about 396 seconds and reached at least 1.12 GiB, but exact peak memory and download bytes were not instrumented.
  • No API key, model call, or real external service was used.

WSL2 path

Install and run Node inside the chosen distribution, keep the workspace in its Linux filesystem, and run the same official package command there. Avoid switching between /mnt/c paths and Linux-owned paths while diagnosing an installation.

WSL2 environment check · bash
uname -a
node --version
npm --version
npx @deepseek-ai/dsh web

Verify more than “the page opened”

A complete startup check includes the process staying alive, the expected address resolving, the model setup opening, a workspace being selectable, and one small read-only task completing. Plugin paths and shell tools must then resolve inside the same environment.

  • Process remains active without a crash loop.
  • Web UI opens at the address printed by DSH; the official default is 127.0.0.1:3080.
  • Model configuration can be saved without exposing the key in screenshots or logs.
  • Workspace paths resolve from the process environment.
  • A read-only first task finishes before broader permissions are granted.

What remains before this page is indexable

The native Windows base lifecycle and one plugin path are now reproduced. WSL2, an API-backed model task, workspace behavior under a real task, and path/permission differences still need retained tests. Until those gaps are closed, this page remains deliberately excluded from the sitemap.

Sources and evidence boundary

Primary sources establish product facts. HarnessBase labels direct testing separately and does not convert community observations into verified results.

Target query cluster: DeepSeek Harness Windows · install DeepSeek Harness on Windows · DeepSeek Harness WSL2