dsh-windows-native
Native-Windows (non-WSL) shell/encoding/filesystem gotchas for the DeepSeek Harness system prompt
- Stars
- 0
- Language
- JavaScript
- Created
- Aug 31, 2026
- Updated
- Aug 31, 2026
Introduction
dsh-windows-native
I run DeepSeek Harness straight on
Windows — no WSL, just PowerShell. Every WSL & Windows Interop plugin on the
dsh-plugin list assumes you're bridging out
from WSL, so none of them help here. Meanwhile the agent kept doing the same handful
of things wrong: chaining commands with && (PowerShell 5.1 doesn't have it), printing
Chinese text that comes back as mojibake, quietly creating a junction that Windows then
refuses and nobody notices. This plugin just tells it up front so it stops guessing.
It's a system-prompt injection, nothing fancier. Copy-pasted the structure from dsh-wsl-env since that plugin already does the WSL side of the same idea well.
What it tells the agent
- PowerShell has no
&&/||— use;, orA; if ($?) { B } - The console usually isn't UTF-8, so Chinese/non-ASCII output can get mangled even though the actual data is fine — don't trust what you see printed
- Don't feed multi-line non-ASCII text through an inline heredoc or
-c "..."— write it to a file first, then run the file - Python's
subprocess.run(..., text=True)decodes child output using the system locale — GBK on a Chinese Windows install, not UTF-8. A subprocess that ran fine can still blow up withUnicodeDecodeErroron its own output. Passencoding="utf-8", errors="replace"explicitly .batfile contents have to stay ASCII (cmd.exe pre-scans them and can corrupt UTF-8/GBK before anything runs — filenames are fine, the script body isn't)Set-Content/Add-Contentwrite files using the system ANSI codepage by default, not UTF-8 — Chinese text written through either without-Encoding utf8can end up corrupted on disk, not just on screen- Nested quotes in an SSH command forwarded from PowerShell (
ssh host "sudo python3 -c \"...\"") can hang silently for minutes past one level of nesting instead of erroring. Write the command to a local file andscpit over instead - A junction or symlink can fail silently without admin rights / Developer Mode — check it actually exists after creating it, don't just trust the exit code
NUL/CON/PRN/AUX/COM1-9/LPT1-9are reserved in every directory. Discarding output the Unix way with> /dev/nulldoesn't hit a null device on Windows — it can leave a literal, barely-deletable file namednulsitting in the working directory. Use$nullinstead (> $null,| Out-Null)- A file open in Word/Excel/WPS throws a plain PermissionError on write. That's not corruption, don't force-retry the same filename
docker run -v "C:\path\file.yaml:/container/path:ro"can get mis-split — the drive letter's colon looks like another separator. The mount silently fails, the container still reports healthy, and it just runs on defaults.docker execin and check the file before blaming the application code- Native (
.node) npm bindings built here are Windows binaries. Shipping them to a Linux server crashes it at runtime even thoughnpm installand the local build both reported success — check for "PE32+"/"MS Windows" withfilebefore shipping - Killing the outer process (a task runner, a job wrapper) doesn't free the port if the real node/python process underneath is still alive — you end up hitting a stale server and think your fix didn't work. Find the real PID and kill that
- If you need a Scheduled Task to run something invisibly,
-WindowStyle Hiddenstill flashes a console window for a moment. Launch it throughpythonw.exewithCREATE_NO_WINDOWinstead
None of this is theoretical — every line above is something that actually went wrong on this machine at some point.
Install
dsh plugin add dsh-windows-native
Config
when: windows # inject only on native win32 (default), or "always"
order: 15
extraNotes: "" # your own notes, appended after the built-in list
Status
Early, and the list is exactly as long as my own scar tissue — not a survey of every Windows footgun that exists. If you hit something this plugin should have warned you about, open a PR with the actual failure you saw, not a guess at what might go wrong.
Tested against @deepseek-ai/dsh 0.1.1-rc.2 — installed it locally as a file:
dependency, checked dsh --dump-config to confirm it's picked up, then actually asked
the running agent a question and watched the injected text come back in its answer.