dsh-wsl-workspace

English · 中文 · 日本語 · 한국어 · Français · Deutsch · Español · Português · Русский Add a WSL workspace from the DeepSeek Harness web GUI and run the whole agent session — bash commands and file reads/writes — inside a local WSL distribution with Linux paths. Nothing needs to be installed inside WSL. The session can reach both WSL and Windows at the same time: bash commands run inside the WSL distribution, while Windows files stay accessible via /mnt/<drive> (for example /mnt/c/Users/...).

Install

Pick one of the three ways below, then restart dsh web:

# 1) npm package
dsh plugin --profile web add dsh-wsl-workspace

# 2) GitHub repository (ships the prebuilt lib/, no local build required)
dsh plugin --profile web add https://github.com/6Mikao9/dsh-wsl-workspace

# 3) Local directory (development / self-hosted)
dsh plugin --profile web add D:\path\to\dsh-wsl-workspace

After restarting dsh web, a W button appears beside Settings at the sidebar foot.

Native build at install time

Installing this plugin pulls @deepseek-ai/dsh-fs-local (a peer dependency), which depends on koffi — a dynamic C FFI for Node.js. koffi runs an install script during npm install (node ./cnoke.cjs -P . -D src/koffi --prebuild --release):

• Prebuilt first: it tries to load a platform-specific prebuilt addon from koffi's optionalDependencies (@koromix/koffi-<platform>), covering win32-x64/arm64/ia32, linux-x64/arm64/ia32/riscv64/loong64, darwin-x64/arm64, freebsd-*, openbsd-*. When a prebuild loads, no compilation happens.
• Fallback compile: only if no prebuilt addon is available/loadable does it rebuild from source, which needs CMake and a C/C++ compiler (Windows prefers Clang, or MinGW under MSYSTEM). This is koffi's own standard behavior; this plugin builds and ships no native code itself.

This is expected and not malicious (koffi is MIT-licensed). Installing with --ignore-scripts skips koffi's addon selection/build, so @deepseek-ai/dsh-fs-local may fail to load on platforms without a cached prebuilt binary. The WSL session itself needs no toolchain: the bash tool runs inside the WSL distribution and the file tools go through the Windows-side WSL share.

Usage

Click the W button beside Settings at the sidebar foot to open the "Add WSL workspace" dialog. Pick a distribution from the list, then browse the directory tree or type an absolute Linux path (for example /home/me/proj) — use the Check button to verify the path exists before creating the workspace. The dialog follows the DeepSeek Harness UI language. The username field is optional: leave it empty to run commands as the distribution's default user, or name a Linux user of that distribution to run the session as that user instead (equivalent to wsl.exe -u <username>). The username only changes the bash tool's run identity — the file tools go through the Windows-side WSL share and are unaffected. Each workspace's username is kept in <dshHome>/wsl-workspaces.json; delete the entry (or recreate the workspace from the dialog) to return to the default user.

Click "Create & open" to start a new session in the workspace. In the new session the bash tool executes commands inside the chosen distribution and read/write/edit operate on WSL files, so every path the model sees is a Linux path. The mode picker keeps working as usual: Standard, PTC, Minimal and Creative each land on their WSL variant automatically (the WSL variant entries in the picker are bilingual, e.g. WSL · Standard mode（标准模式）), and Windows files stay reachable from inside the session under /mnt/<drive> (for example /mnt/c/Users/...).

Behavior notes

• bash tool: runs inside the WSL distribution as the configured username (empty = the distro default user, often root), so it can read and write anywhere in the distro. The Windows ACL sandbox cannot wrap wsl.exe — its children run on the Linux kernel side — so WSL itself is the isolation boundary and the DSH file policy does not apply to bash.
• File tools (read/write/edit): go through the Windows-side WSL 9P share and run under the DSH file policy. Under workspace-write, reads work anywhere but writes are restricted to the session workspace; switch the file policy to danger-full-access to also allow writes outside it. The username field does not affect the file tools.
• The garbled localhost port-forwarding banner wsl.exe prints to stderr when the distro was not running yet is harmless.
• Mode variants: for every mode DSH ships — Standard, PTC, Minimal, Creative, and experimental ones like Anchored Standard — this plugin adds a matching wsl-<mode> variant. The original modes stay available unchanged; the WSL variants simply run the same mode inside a WSL execution world.

Changelog

0.2.4

• Fixed #5 — WSL Minimal mode no longer breaks the first-request "we need/lets" thinking chain. The WSL variant of a minimal-like preset (one that only exposes persistent-bash + str-replace-editor) previously also injected the one-shot bash tool plus the read/write/edit/read_image file tools; the duplicated bash tool name and the extra schemas inflated the first-request tool catalog and derailed the chain of thought. Minimal-like variants now keep only persistent-bash, str-replace-editor and the fs-wsl provider; standard-like presets still receive the full shell + file-tool world.

License & attribution

MIT — see LICENSE and NOTICE. The NOTICE precisely lists:

• Adapted/inherited source code: DeepSeek Harness (MIT) — dsh-bash-local (executor mechanics), dsh-fs-local (WslFileSystem subclasses it), and the shipped agent presets (read and transformed by the variant generator);
• Design references (no source copied): dsh-bash-terminal (MIT, wsl argv / WSLENV approach), dsh-side-panel (BSD-3-Clause, host-route pattern), vpshub (MIT, roadmap reference).

Keep LICENSE and NOTICE when redistributing.

Acknowledgments

Special thanks to dsh-deep-whale (DSH Web 鲸鱼娘 skin series · 深海女仆工坊 maid-atelier, CC BY-NC-SA 4.0): the whale girl skin plugin brings a full set of adorable skins to the DeepSeek Harness Web UI and makes daily use of DSH a warmer experience.