@yujyf/dsh-remote-workspace
DeepSeek Harness 的本地/WSL 远程工作区执行路由：配置档案包与侧边栏工作区选择器
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:Yujyf/dsh-remote-workspace#8c3c3534e6ac1c3dbe752252190dd8c5b08288b8Remote Workspace 以 @yujyf/dsh-remote-workspace 发布，当前版本为 0.1.5。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
点击下方 Badge 复制 Markdown，粘贴到 README 即可。
验证 package.json 声明的 GitHub 仓库，即可管理这个公开页面。认领后，Hub 会优先安排当前版本的安全扫描，并在通过后公开展示结果。
认领这个 Plugin →Run one DSH session inside a Local or WSL execution world, chosen per session from the Web GUI, without forking DSH and without adding a single wsl_* model tool.
DSH ships one filesystem backend and one subprocess backend per profile. This package replaces both with routers: every existing model tool (bash, read_file, write_file, edit_file, …) keeps its name and schema, while the backend underneath resolves the session's current workspace binding and delegates to the right execution world.
wsl.exe; file and process operations run inside that distribution with POSIX paths, its own home, and its own toolchain.One sidebar entry registers the selector: pick a target, browse to a folder, register it as a workspace, and bind it to the open session. From the next model request on, that session's shell commands, file reads and writes, and file searches execute there, with the bound directory as their working directory, and a runtime-context note tells the model which world it is in and to use bash.
The selector lists remote worlds only. The host's own world is never offered, because a session with nothing bound already runs there; on a Windows host the list is one row per WSL distribution. DSH's own workspaces appear beside them under Local, and the world filter narrows the list to a single execution world.
Every remote workspace is also registered as a DSH workspace, under the distribution's UNC view of its directory (\\wsl.localhost\Ubuntu-26.04\home\me\project) and titled <name> · WSL <distro>. That entry is what puts the workspace into DSH's own workspace list and in front of every other plugin reading ctx.workspaceRegistry, instead of living only in this package's registry; removing the registration removes it again. A session created in that workspace from DSH's own surface runs in the distribution without any binding, because the session directory already names the world.
Run on the host again releases the binding: the session goes back to running on the host, and nothing is deleted.
| DSH | >=0.1.0 <0.2; verified on 0.1.2-rc.1 (the version the desktop app ships) and built against the 0.1.5-alpha.2 type surface |
| Node | ^22.19 || >=24 |
| OS | Windows 10/11 for WSL targets; on macOS and Linux the selector has no remote world to offer |
| WSL | wsl.exe on PATH, with at least one registered distribution |
WSL targets are only enumerated on Windows (process.platform === 'win32'). On every other platform the remote target list is empty, and sessions keep running in the host world.
dsh plugin --profile web add github:Yujyf/dsh-remote-workspace
The command forwards to pnpm inside the profile directory and then reconciles dsh.profile.bundles, so this package's cordis.patch.yml joins the profile's patch layer automatically. Restart the profile (or reload the Web GUI) to compose it.
Prebuilt lib/ is committed, so the install runs no build step. Removing it:
dsh plugin --profile web remove @yujyf/dsh-remote-workspace
Available, Starting, Stopped, or Unavailable; connecting a Stopped distribution starts it.<name> · WSL <distro>.bash, file reads, and file writes for that session execute in that directory. Relative paths resolve there, and the next request tells the model its world, directory, and to use bash instead of pwsh.A session with no binding keeps running on the host. Binding is per session, so two open sessions can execute in two different worlds at the same time.
Five Cordis plugins, one capability seam each:
| Entry | Service | Role |
|---|---|---|
. | ctx.remoteWorkspace | Owner: targets, workspace registrations, connect/disconnect, session binding, health, directory listing, canonical URI resolution |
./fs | ctx.fs | Filesystem router: local binding → isolated sandboxed backend; WSL binding → helper-backed WslFileSystem |
./subprocess | ctx.subprocess | Process router: local binding → isolated local backend; WSL binding → wsl.exe argv translation |
./controller | ctx.webServer route | JSON API the browser half calls: POST /remote-workspace/api/<verb> |
./ui + ./client | sidebar slot | Selector entry, panel, folder browser |
cordis.patch.yml disables the shipped subprocess and fs-sandbox rows and inserts these five, so exactly one provider serves ctx.fs and ctx.subprocess in the composed tree.
The browser half talks to the Host over a plain JSON route rather than a Remote namespace. DSH mounts Remote namespaces from a fixed list compiled into @deepseek-ai/dsh-api-remotes, so a package outside that assembly cannot contribute one; the client fiber would then wait forever for remote.<namespace> and the Web shell would never finish booting. The route applies the same browser-trust fence as the /api gateway: the request's Host authority must be loopback, or an authority the deployment declares in webRuntime.trustedHosts.
Design constraints this package holds to:
wsl_* tools. Execution worlds are selected by the backend, not by the model's choice of tool name.cwd. A WSL workspace is never presented to Windows as \\wsl.localhost\… or /mnt/c/…; paths stay native to the world that executes them.DSH fixes a session's working directory when the session is created, and that header is immutable. Binding therefore does not rewrite the session; the routers translate each request instead:
E:\work\project) becomes the bound workspace directory (/home/me/project), which is where a defaulted or relative tool path lands.C:\Users\me is /mnt/c/Users/me), so an explicit workdir still reaches the host file it names.bash is the shell to use — PowerShell does not exist inside WSL.The session's recorded directory is read from the live session; the binding stays durable, so a restart rebinds the same world.
Set on the inserted remote-workspace row in the profile's cordis.yml (defaults shown):
- id: remote-workspace
name: '@yujyf/dsh-remote-workspace'
config:
autoStart: true # start a stopped distribution when one of its workspaces connects
shutdownOnDisconnect: false # never terminate a distribution another session may be using
commandTimeoutMs: 30000 # ceiling for one wsl.exe invocation
\\wsl.localhost\<distro>\…; that is also what a session created there records as its directory. Registering one therefore needs the distribution running (the flow connects first), and a distribution stopped afterwards leaves that workspace's directory unresolvable to DSH.pwsh cannot run in a bound session. PowerShell does not exist inside WSL; the note directs the model to bash. The tool stays in the schema because DSH selects tools by host platform.shutdownOnDisconnect: true.pnpm install
pnpm run typecheck # host face + client face
pnpm run test # behavior tests for the pure workspace-identity helpers
pnpm run build # tsc (host face, client declarations) + esbuild browser bundle
lib/ is committed on purpose: a git install must not need a build step, and pnpm blocks dependency build scripts until they are allowlisted. Rebuild and commit lib/ together with any source change.
Layout:
src/ host face: owner, fs router, subprocess router, controller, wire types
src/client/ browser half: slot entry, panel component, store, dictionaries
tests/ behavior tests, run against the built lib/
cordis.patch.yml the profile layer this package contributes
scripts/build.mjs tsc + esbuild closure-factory bundle for the browser half
The two compiler faces stay separate because the host face pulls in @deepseek-ai/dsh-session's Host ctx.sessions merge, which conflicts with the Client Session object layer's merge of the same member.