dsh-win32

What it solves

• On native Windows without WSL, DSH frequently fails to launch or fails checks, and the causes are hard to pin down: PowerShell 7 environment issues, broken koffi runtimes, leftover legacy plugin bundles.
• dsh-win32 provides four commands:
  • setup: checks the published DSH Windows package contract and PowerShell 7, detects known-broken koffi runtimes, creates a DeepSeek Harness desktop shortcut, and leaves the official profile and preset on the stock Minimal setup.
  • doctor: verifies the Windows package contract and inspects local Windows failures; --json follows the dsh-doctor/v1 envelope.
  • verify: a model- and API-key-free live acceptance run against an already installed dependency tree — persistent pwsh keeping the same PTY, working directory and environment; write/read inside a temporary workspace; a normal-process control can write the outside target while confined PowerShell is denied and creates no file; recovery after denial and clean teardown on cancellation; then all temporary resources are removed.
  • fix: repairs only installed koffi versions that are known broken or fail a real runtime load, then re-verifies the load.
• It also offers a disable/uninstall path for the legacy bundle, even when DSH cannot start.

Who it’s for

• Developers running DSH on native Windows who do not want to introduce WSL.
• Maintainers who distribute or support DSH on Windows and want reproducible diagnostic and acceptance steps.
• Users stuck on koffi / PowerShell 7 / Workspace Write sandbox failures who need one command to diagnose and repair.

Usage

npx dsh-win32 setup
npx dsh-win32 setup --verify
npx dsh-win32 doctor --json
npx dsh-win32 fix

Caveats

• Use the standalone CLI above; do not run dsh plugin --profile web add dsh-win32, which installs the legacy bundle rather than the current Windows setup path.
• A verify pass is component-chain acceptance only: it does not start a complete stock Minimal session, run the plugin installer, or prove hook enforcement.
• If you run verify from inside another sandbox, approve one unsandboxed execution for that command only, or nested restricted-token/ConPTY layers may stall.