Preface¶
It is a common setup to run DeepSeek Harness (dsh) on Windows while keeping the code inside WSL. The project relies on apt, gcc, Linux paths, and POSIX scripts, but the agent works in the Windows-side session: the bash tools do not match the WSL distro, the file utilities see C:\... paths, and any changes need to be manually synced to \\wsl.localhost\.... Conversely, installing the full dsh stack inside WSL means maintaining two runtime environments, switching back and forth between paths, configurations, and the web UI.
The official positioning of DeepSeek Harness is “Everything is a plugin”: models, tools, sessions, sandboxes, and UIs can all be replaced at the configuration layer without modifying the framework source code. The community directory DeepSeek Harness Plugin Repository collects a range of such extensions. Note that this directory is an independently operated community site and has no affiliation, endorsement, or sponsorship relationship with DeepSeek or Ho Fung. This article introduces one such interface enhancement plugin, dsh-wsl-workspace: after installation, you can directly add a WSL workspace through the web UI, and the entire agent session (bash and file operations) will run in the native WSL distro without needing to install a separate copy of dsh inside WSL.
The content below is cross-checked against the plugin directory page, the GitHub repository’s README / package.json / design documentation, and the DeepSeek Harness official repository.
What It Is¶
dsh-wsl-workspace is a plugin for the DeepSeek Harness Web UI, maintained by GitHub user 6Mikao9 at the repository 6Mikao9/dsh-wsl-workspace. It uses the MIT license and is primarily written in TypeScript. The directory categorizes it under “Interface Enhancements”. The current version in package.json is 0.2.3, and it declares the client platform as web. As of 2026-08-18, both the directory page and GitHub repository show 7 stars. The plugin was added to the directory on 2026-08-14, and the last push to the repository was on 2026-08-16.
The problem it solves can be summarized in one sentence: in dsh web running on a Windows host, switch the entire workspace to the native WSL distro, instead of just adding an extra shell tool that can run wsl.exe. The maintainer wrote in DESIGN.md that the target runtime configuration is “dsh web on Windows + native WSL2 distro”, and compared it to community solutions that only add an extra shell tool (such as dsh-bash-terminal): in those solutions, commands can run inside WSL, but read/write/edit still operate on the Windows file system. This plugin replaces a set of session-aware capability providers (ctx.shell + ctx.fs), so all paths seen by the model use Linux format.
The description in package.json compares it to VS Code’s Remote-WSL: add a workspace through the GUI, and the entire session executes inside the distro. The repository README emphasizes two points: no dsh toolchain needs to be installed inside WSL; the same session can also access Windows files via /mnt/ (for example, /mnt/c/Users/...).
Core Features¶
Add WSL Workspace via Web UI¶
After installing and restarting dsh web, a W button will appear next to Settings at the bottom of the sidebar. Clicking it opens the “Add WSL Workspace” dialog, with copy text matching the DeepSeek Harness UI language.
The workflow is detailed in the README:
1. Select a native WSL distro from the dropdown menu.
2. Browse the directory tree, or directly enter a Linux absolute path (for example, /home/me/proj).
3. Click “Check” to confirm the path actually exists in the distro.
4. Username is optional: leave it blank to run as the default user for that distro (the README notes that the default user is often root); fill in a Linux username from the distro, and it is equivalent to wsl.exe -u <username>.
5. Click “Create and Open”, and the new session will immediately attach to this WSL workspace.
The username only changes the execution identity of the bash tool; the file tools use the Windows-side WSL share and are not affected by this field. The username for each workspace is written to wsl-workspaces.json; deleting the corresponding entry or recreating the workspace in the dialog will revert to the default user. The design documentation also specifies that the dialog will reject using the distro root directory / as a workspace.
Entire Session Runs on Linux Paths¶
In the new session, the bash tool executes commands inside the selected distro, read/write/edit operations access WSL files, and all paths seen by the model use Linux format. The maintainer used uname -a as a validation point in the M1 acceptance criteria: the session should show Linux, not Windows.
The file tools are implemented via the Windows-side WSL 9P share (UNC path in the form \\wsl.localhost\<distro>\...), which is translated to Linux paths at the presentation layer. This is why “zero installation inside WSL” works: there is no need to run a separate file proxy inside the distro.
Mode Selector Remains Functional¶
The plugin does not make “entering WSL” an exclusive single preset that overrides Standard / PTC / Minimal / Creative modes. The README states that the mode selector works as normal, and Standard, PTC, Minimal, and Creative modes will automatically fall back to their corresponding WSL variants; the selector entries are bilingual, for example WSL · Standard mode.
The design documentation refers to this combination as “Execution World and Mode are Orthogonal”: WSL is the execution world, while Standard / PTC / Minimal / Creative remain the original modes, and the two combine to generate wsl-<mode> variants. For users, selecting a workspace switches to WSL, and selecting a mode follows their original habits.
Simultaneous Access to WSL and Windows¶
The session can access both environments. Bash commands run inside the distro; files on Windows are accessed via /mnt/, for example /mnt/c/Users/.... The design documentation calls this joint access: fs-wsl maps /mnt/<drive letter>/... back to Windows drives for direct read/write, and the UI still displays the /mnt format.
This is convenient for scenarios where “the project is in WSL, but individual configurations or assets are still in the Windows user directory”, eliminating the need to open a local workspace just to read a Windows path.
Different Permission Boundaries for Bash and File Tools¶
The README has a separate “Behavior and Permission Notes” section that should not be overlooked:
- Bash tool: Runs inside the distro with the configured username, and can read/write any path inside the distro. Windows ACL sandboxes cannot wrap wsl.exe (subprocesses run on the Linux kernel side), so the isolation boundary is WSL itself. DSH’s file policies do not apply to bash.
- File tools (read/write/edit): Accessed via the Windows-side 9P share, subject to DSH file policies. Under workspace-write, reads can access any location, while writes are restricted to the current session workspace; changing to danger-full-access allows writes outside the workspace. The username setting does not affect the file tools.
Additionally, if the distro was not running at the time, wsl.exe sometimes prints localhost port forwarding prompts to stderr. The README notes that these are garbled but harmless and can be ignored.
Installation and Activation¶
The installation command provided on the directory page should be run in the DeepSeek Harness terminal:
dsh plugin add github:6Mikao9/dsh-wsl-workspace
For reproducible installations, the directory page recommends pinning the commit hash (replace commit with the actual hash, do not keep the placeholder):
dsh plugin add github:6Mikao9/dsh-wsl-workspace#commit
This plugin is attached to the web UI. The repository README provides three ways to install it into the web profile, and you need to restart dsh web after installation:
# 1) npm package
dsh plugin --profile web add dsh-wsl-workspace
# 2) GitHub repository (pre-built lib/ is included in the repository, no local build required)
dsh plugin --profile web add https://github.com/6Mikao9/dsh-wsl-workspace
# 3) Local directory (for development / personal use)
dsh plugin --profile web add D:\path\to\dsh-wsl-workspace
After restarting, the W button will appear next to Settings at the bottom of the sidebar, indicating that the client component has been attached. The directory page also reminds users that they can use dsh plugins list to confirm whether the plugin has been loaded into the current configuration.
Please read the repository source code and the MIT license before installing. The plugin runs with the permissions of the current dsh process, and may execute code during installation; both the community directory and official documentation recommend only installing sources you have reviewed, and pinning commits when a reproducible environment is required.
Typical Usage¶
Follow the UI workflow from the README below, without inventing extra configuration items.
1. Confirm that there is an available WSL distro on the local machine (for example, Ubuntu). The plugin will not install dsh inside WSL, but the distro itself must exist, and wsl.exe must be callable by the dsh process on Windows.
2. Install the plugin into the web profile and restart dsh web.
3. Open the web UI, and click the W button next to Settings at the bottom of the sidebar.
4. Select the distro, and enter or browse to the project directory, for example:
/home/me/proj
- Click “Check”, confirm the path exists, then click “Create and Open”.
- In the new session, ask the model to run a command that identifies the kernel (the maintainer’s own validation method is
uname -a), and read/write files in the workspace. The paths should now use Linux format; if you need to access files on Windows, use paths like/mnt/c/.... - When you need to switch modes, directly select entries like
WSL · Standard modefrom the selector without exiting the workspace. - If bash needs to run as a non-default user, fill in the Linux username from the distro in the dialog; this only affects the command execution identity and does not change the access channel for file tools.
The repository README includes interface screenshots (image-2.png, image-3.png), which you can refer to after installation to verify the button positions and dialog layout.
Applicable Scenarios and Notes¶
This plugin is suitable for these scenarios:
- You regularly run dsh web on Windows, but your repositories, build scripts, and dependencies are all inside WSL.
- You want the agent to work with Linux paths and bash syntax, without maintaining a separate copy of dsh inside WSL.
- A single task requires modifying WSL projects while also reading files from the Windows user directory.
Before using it, be aware of these boundaries:
1. Platform: Targets Windows host + native WSL. The keywords in package.json include windows; the design documentation specifies WSL2. macOS / Linux native machines do not have wsl.exe, so this plugin has no corresponding functionality.
2. Not just adding a WSL shell: If you only want to occasionally run a few Linux commands in a Windows session, there are community plugins that only register an extra shell tool. This plugin switches the execution world per session, and file tools will also operate inside WSL.
3. Bash is not bound by DSH file policies: Windows ACL sandboxes cannot contain wsl.exe. When handing over the workspace to the default user (especially root), the read/write scope inside the distro is determined by WSL itself. To tighten permissions, you should specify a regular Linux user in the dialog, and use danger-full-access cautiously.
4. File policies still apply to file tools: You cannot use write/edit to modify WSL files outside the workspace under workspace-write; this is not a bug, it is intended policy.
5. Permissions and Source: The plugin runs with the same permissions as the current dsh process. Check the source repository and license before installing; do not treat the community directory as an official app store.
6. Unreleased roadmap features listed in README: The design documentation lists the sidebar file tree panel, interactive terminal, and SSH remote workspace as future milestones. The current README usage only covers the “Add WSL Workspace” dialog and in-session bash / file tools, and this article does not cover features that have not been delivered as per the design draft.
When redistributing or modifying the code, the repository requires retaining LICENSE and NOTICE. The NOTICE clarifies: the executor mechanism is adapted from DeepSeek Harness’s dsh-bash-local, WslFileSystem subclasses dsh-fs-local, and the design references dsh-bash-terminal (WSL argv / WSLENV) and dsh-side-panel (Host routing mode), but no source code from the latter two was copied.
Summary¶
dsh-wsl-workspace has a focused purpose: it enables the DeepSeek Harness web UI on Windows to directly open WSL workspaces, with bash and file tools running inside the distro, using Linux paths. No additional dsh installation is needed inside WSL, and Windows files are still accessible via /mnt/. For users who have already moved their development environment to WSL but want to continue using dsh web, this plugin eliminates the need to maintain two separate runtime environments.
Plugin Directory: https://deepseek-harness-plugin.com/en-US/plugins/dsh-wsl-workspace/
GitHub: https://github.com/6Mikao9/dsh-wsl-workspace