Native Windows or WSL? Which should I choose for DeepSeek Harness?

Choose native Windows for desktop apps and daily office work, and WSL for Linux tooling and server-like environments. Do not run both against the same DeepSeek Harness data directory.

Why is dsh not found in PowerShell on Windows even after npm install?

dsh not found on Windows after npm install usually means the npm global bin directory is off PATH. Check npm prefix and PATH, then reopen the terminal.

Should DeepSeek Harness plugins go in Windows directories or WSL directories?

Plugins belong inside the environment where DeepSeek Harness runs: native installs use Windows paths, WSL installs use WSL paths. Mixing them makes plugins invisible.

The WSL service is running but the Windows browser cannot open it. Why?

A WSL service that the Windows browser cannot open is usually a listening address or WSL network issue. Confirm the service listens on a reachable address, or use port forwarding.

DeepSeek Harness on Windows: native and WSL setup

Windows has two paths: native Node or desktop, and WSL. They differ in command lookup, path style, line endings, and networking; running both at once is the most common source of "it worked yesterday."

Two paths compared

Choose by toolchain and environment.

Dimension	Native Windows	WSL
Runtime	Windows Node or desktop	Linux inside WSL
Path style	C:\Users...	/home/...
Toolchain	Windows native tools	Linux tools
Browser access	Local directly	localhost or forwarding
Suits	Desktop, office	Development, servers

Native is closer to daily Windows use and WSL closer to Linux habits. Desktop packages integrate with Windows windows and file dialogs; WSL installs commands and scripts, and browser access is direct. Do not mix environments: a native service with WSL-installed plugins cannot see them.

Native Windows: Node and desktop

Three steps: Node, PATH, and verification.

Install a supported Node.js and confirm node -v.
Install globally or use npx.
Confirm npm prefix and whether the global bin is on PATH.
Start dsh web and open the browser.
Check the version and service address.

The most common issue is PATH, and a wrong terminal hides it. Windows PowerShell, CMD, and Git Bash have different PATHs; a command working in one may not in another. Reopen the terminal after installing; environment changes do not affect open sessions.

Desktop packages avoid Node setup. Install from Releases for Windows, then configure models and plugins in the app; updates go through the app. Confirm the publisher and signature.

WSL: Linux habits

WSL gives a Linux toolchain inside Windows.

Install a WSL distribution and confirm it starts.
Install Node.js and dependencies inside WSL.
Install DSH inside WSL, not on the Windows side.
Start the service and open the address from the Windows browser.
Keep data under the WSL home directory.

Install inside the environment that runs the service, and avoid cross-file-system writes. Projects under /mnt/c are slower with permission and line-ending issues; keeping data under the WSL home is more stable. WSL2 localhost forwarding usually works; if not, check listening address and port mapping.

Path mixing and line endings

Cross-environment paths and line endings cause four failures.

Plugins invisible: installed in the other environment; confirm the running environment.
Script errors: CRLF vs LF and different shells.
Path not found: C:\ style paths unrecognized in WSL.
Slow access: cross-file-system reads and writes.

The fix is one environment, one data directory, one toolchain. Do not edit WSL files with Windows tools while running the service in WSL; changes and locks conflict.

Convert line endings deliberately. For scripts and configuration edited across systems, use an editor that explicitly controls line endings.

Access and networking

How Windows reaches the service depends on where it runs.

Native: the service listens locally; the browser opens localhost or a LAN address.
WSL2: localhost forwarding usually works; otherwise use port forwarding.
LAN sharing: map to a reachable address, evaluate authentication.
Firewall: Windows Firewall may block LAN access.
Remote: reverse proxy or tunneling, same as Linux.

"Service running, browser cannot open" is usually address or firewall. curl the address inside the environment first; success means a network or firewall issue, failure means the service itself.

Three failures

Three common Windows failures.

Command not found: PATH or different terminals; check npm prefix.
Port occupied: another process uses it; change the port or stop the process.
Permissions denied: install directory or file locks; do not install to system-protected directories.

Each has a clear confirmation method. Command lookup, port check, and permission check; guessing skips them all.

Security notes

Windows and WSL share exposure surfaces.

Localhost-first for port mapping.
Evaluate authentication for LAN sharing.
Install plugins from verified sources.
Keep data directories out of public shares.
Back up before switching environments.

Environment switching is a migration, not a copy. Confirm the data directory, plugin list, and versions before switching.

Next steps

Choose native or WSL, then keep environments separate. For install methods, read How to install DeepSeek Harness: 4 methods. For Linux desktop, read Running DeepSeek Harness desktop on Linux. For data directories, read How updates keep your data.

Sources: DeepSeek Harness docs, dsh CLI README, DeepSeek Harness Releases