DeepSeek Harness Windows Install: PowerShell and WSL
Choose native PowerShell or WSL before installing and keep the first checks in that environment. Verify Node and npm there, launch the pinned official package from your intended project directory, then select the workspace and model. Record the Windows or WSL context when reporting a failure.
Sharing includes the public link only, without local progress or private configuration.
Start with this command
This is the narrow command relevant to this page. Read the checks below before changing flags, credentials or profile patches.
npx @deepseek-ai/dsh@0.2.0-rc.2 web1. Choose native PowerShell or WSL
Open PowerShell for a native Windows test, or open your WSL distribution for a Linux-side test. Check node --version and npm --version in the chosen terminal. Node working in PowerShell does not prove it exists in WSL, and a WSL command does not select your Windows installation.
Use the project path understood by that shell: a native Windows directory in PowerShell, or the intended Linux/mounted path in WSL. Confirm the current directory before launching; crossing environments during a test makes executable, permission and workspace errors harder to reproduce.
node --version
npm --versionWhat to check: Both versions print in the same PowerShell or WSL environment that will run DSH.
2. Launch the pinned package and check the URL
Run the version check, then start the Web UI. Keep the terminal open and visit its printed URL. If a browser does not open automatically, try the printed URL manually before reinstalling. If the server exits, keep the first diagnostic and your shell identity.
Use the port chosen by that invocation. A stale browser tab can point at an older server, especially when testing multiple versions. For WSL or remote development, confirm which service the forwarded browser address reaches.
npx --yes @deepseek-ai/dsh@0.2.0-rc.2 --version
npx --yes @deepseek-ai/dsh@0.2.0-rc.2 webWhat to check: The version check identifies 0.2.0-rc.2; the next command stays running and prints a reachable local Web UI URL.
3. Verify the workspace, model and platform boundary
Choose the intended project in the Web UI, then save a provider in Settings → Models. Start a fresh session and ask for the repository’s test command without changing files. Compare the named file yourself.
Native Windows and WSL have different process and filesystem behavior. The historical WSL2 Windows interop report #3045 is unconfirmed and was not independently reproduced: it reported that Windows interop processes could act outside a Linux mount namespace. That historical report does not establish a current-version flaw or fix. The earlier native Windows workspace-picker report #527 is also a community observation, not a current-version reproduction.
Do not infer that workspace-write constrains every Windows interop process from a successful WSL startup check. Review the current platform sandbox documentation and use a disposable workspace for a separate permissions test; a model’s correct answer about a file does not test containment.
Keep installation and runtime evidence separate
The launcher commands here pin npm latest 0.2.0-rc.2, checked on 2026-10-04. The reviewed upstream documentation is dsh-v0.2.1-alpha.1. The site’s retained local runtime record remains 0.1.0-rc.7 on Linux x64 with Node 22.22.1; it does not establish successful execution of the current package on this platform.
After any upgrade, record the new version and repeat the local-page and first-model-request checks. A Python SDK installation is a separate package path and does not install the Node Web launcher.
Frequently asked questions
Do I need both PowerShell and WSL?
Choose the environment in which you intend to use the project. Completing one native or WSL test first gives you a clear baseline. Treat a later switch as a separate installation and verification.
Why is node recognized in one terminal but not another?
Each shell can have a different PATH and runtime installation. Run both version checks in the exact shell launching dsh and restart that shell after changing Node.
What should a Windows failure report include?
Include the dsh and Node versions, Windows version, PowerShell or WSL identity, workspace filesystem type, failure stage and first sanitized diagnostic. These distinguish a native Windows issue from a Linux-side or forwarding issue.
First-party sources
Open the pinned or retrieved source before acting on a changed release candidate.
- Official DeepSeek Harness run guideOfficial documentation · retrieved 2026-10-04↗
- Official CLI behavior referenceOfficial documentation · retrieved 2026-10-04↗
- Official Web UI guideOfficial documentation · retrieved 2026-10-04↗
- Official model configuration guideOfficial documentation · retrieved 2026-10-04↗
Community reports
These are open user reports hosted in the official repository. They are not publisher confirmation and have not been independently reproduced by this guide unless a separate local reproduction is linked.