dsh-remote-wsl

dsh-remote-wsl

English | [简体中文](README.zh.md)

Open a project inside a WSL distribution directly in DeepSeek Harness (DSH): "Add workspace" gains a Connect WSL entry, where you pick a distribution, browse Linux folders, and make the selected directory a DSH workspace. In that workspace the sidebar terminal runs inside the distribution, and the agent's bash / read / write / edit / glob / grep likewise execute on the Linux side.

> Target environment: Windows 10/11 + WSL2. The plugin uses only official DSH services; it neither depends on nor calls any third-party WSL plugin.

What it does

1. Entry point. The "+" in the sidebar workspace header and "Add workspace" on the new-session page share one add flow. The dialog now first asks where the folder is:

• Local folder: the original Windows directory picker, unchanged.
• Connect WSL: the row below "Local folder"; open it to choose a distribution.

2. Choose a distribution. The "Connect WSL" dialog lists every distribution on the machine (stopped ones included) with its running state, and can refresh from the top-right corner. Distributions are enumerated with wsl.exe -l -v --all; UTF-16LE output is detected automatically, * marks the default distribution, and the list is cached for 5 seconds.

3. Choose a project. After a distribution is selected, browsing starts at that distribution's default user $HOME:

• Breadcrumbs (Ubuntu / home / me) are clickable;
• The search box filters the current level, and you can also type a Linux path to jump there;
• Hidden folders can be shown or hidden;
• Select the current folder and click "Confirm".

4. Register as a workspace.

• Projects on the Linux filesystem are registered as \\wsl.localhost\\ (the \\wsl$ fallback form is probed automatically).
• Projects under /mnt//... are registered as the real Windows path (for example D:\work\proj) — WSL's 9P share denies access to /mnt, so only the real drive path is readable and writable; the plugin remembers which distribution it came from.
• Afterwards, in a new session, the workspace is an ordinary DSH workspace; only the execution plane differs.

5. Terminal inside the distribution. Opening the sidebar terminal in this workspace actually runs

wsl.exe -d --cd , that is the distribution's login shell, starting in the project directory.

6. Agent tools inside the distribution. In sessions of this workspace:

| Tool | Behavior |

|---|---|

| bash | Runs bash -lc inside the distribution, with the workspace as the default directory; every call is a fresh shell |

| read / write / edit | Use Linux paths; writes and edits publish atomically via a temporary file plus rename (WSL's 9P share does not support DSH's native hard-link publish) |

| glob / grep | Search inside the distribution with globstar / GNU grep |

Windows PowerShell tools are hidden in WSL workspaces; ordinary Windows workspaces are unaffected.

Installation

Install the local directory from DSH's Plugins page, or:

dsh plugin --profile web add github:MFJip612/dsh-remote-wsl

The repository contains TypeScript sources only. Run npm ci (which builds automatically) or npm run build before installing a local directory. GitHub installs build through prepare; if pnpm blocks build scripts, allow the exact package key reported by the installer in that profile's pnpm-workspace.yaml, then retry. Alternatively, run npm pack and install the tarball containing compiled artifacts.

You can also ask the agent in a session to install that directory with the plugin manager. link: only guarantees that files in this directory are read; it does not guarantee a running Host reloads code. Under the default configuration, Host-side code changes require a full quit and restart of DSH; browser-side code changes only need a page refresh. DSH's default HMR configuration is root: [], which watches only configuration files. If the quit prompt reports a running task, wait for it to finish before restarting.

File changes and delivery cards

Before publishing, WSL write / edit enter the official fs/write-intent / fs/edit-intent so DSH captures the pre-edit content; on success they record fs/observed. Tool results reuse the native write/edit output format, metadata, and diff presentation, and the official workspace-changes produces the modified-file list and comparison at turn end. Read-only, out-of-bounds, unobserved, and stale-version writes are still rejected.

present keeps using the official executor and the deliverables/presented event; the plugin converts Linux absolute paths, relative paths, ~/, and mounted-drive paths into paths Windows can access, preserving descriptions, file limits, regular-file validation, and click-to-preview/open behavior. UNC paths pointing at another distribution are rejected.

The modified-file list automatically aggregates successful modifications from file tools; a standalone file card is still published by the model calling present, and the plugin does not publish a card for every source change automatically. When files are modified only through bash, non-Git directories lack the file tools' pre-capture; ask the model to call present explicitly when you need a standalone card.

Configuration fields

Override the plugin row's config in the profile's cordis.patch.yml:

- id: dsh-remote-wsl
  name: 'dsh-remote-wsl'
  config:
    terminal: true
    tools: true

| Field | Default | Description |

|---|---|---|

| terminal | true | Whether the sidebar terminal of WSL workspaces opens inside the distribution |

| tools | true | Whether to enable Linux-side tools for sessions of WSL workspaces |

| execTimeoutMs | 15000 | Timeout for a single wsl.exe call (milliseconds) |

| distroCacheMs | 5000 | Cache duration for the distribution list |

| maxEntries | 2000 | Maximum entries returned for one directory lev