前言¶

DSH 开新会话时默认只认 Windows 目录。如果你的项目构建、测试、运行都在 WSL 发行版里（Windows 10/11 + WSL2 环境），常见做法是把工程路径写进 Windows 侧，然后手动切到 Linux 终端里执行，agent 的 bash 一类工具跑在 Windows 上，和真实的构建环境对不上。下面介绍的插件 dsh-remote-wsl 就是解决这件事的：它在 DSH 的「添加 workspace」流程里加了一个 Connect WSL 入口，让你直接在 WSL 发行版里浏览目录、选一个 Linux 路径作为 workspace。插件由 MFJip612 维护，仓库地址 https://github.com/MFJip612/dsh-remote-wsl ，许可证 MIT。它只使用 DSH 官方服务，不依赖也不调用任何第三方 WSL 插件。

这是什么¶

一句话：让 DSH 的 workspace 指向 WSL 发行版内的目录，并把该 workspace 的终端和 agent 工具放到 Linux 一侧执行。

已有做法的问题在于，Windows 路径下的 workspace，agent 执行 bash 时用的是 Windows 侧的工具链；而 WSL 项目的工具链在发行版里，两边路径、环境变量、文件系统视图都不同。这个插件不需要你在项目里加任何包装脚本，装好之后在挑选目录的对话框里多一个选项。

核心功能¶

入口。 侧栏 workspace 头部的「+」和新会话页的「Add workspace」共用同一个添加流程。对话框先问文件夹从哪里来，第一项 Local folder 是原有的 Windows 目录选择，行为不变；第二项 Connect WSL 是新加的行，展开后选择发行版。

选发行版。 Connect WSL 对话框列出本机所有发行版（包括已停止的），并显示运行状态，右上角可以刷新。列表通过 wsl.exe -l -v --all 枚举，自动识别 UTF-16LE 输出，* 标出默认发行版，列表缓存 5 秒。

选项目。 选定发行版后，浏览从该发行版的默认用户 $HOME 开始。面包屑（如 Ubuntu / home / me）可点击；搜索框过滤当前层级，也可以直接输入 Linux 路径跳转；可以切换是否显示隐藏文件夹；选中当前目录后点 Confirm。

注册为 workspace。 Linux 文件系统上的项目注册为 \\wsl.localhost\<distro>\<path>（会自动探测 \\wsl$ 兜底形式）。/mnt/<drive>/... 下的项目则注册为真实 Windows 路径（如 D:\work\proj），因为 WSL 的 9P 共享不允许访问 /mnt，只有真实盘符路径可读可写，插件会记住它来自哪个发行版。注册完成后，新会话里它就是一个普通 workspace，只是执行平面不同。

发行版内的终端。 该 workspace 打开侧栏终端时，实际执行的是 wsl.exe -d <distro> --cd <linux path>，即发行版的登录 shell，起始目录就是项目目录。

发行版内的 agent 工具。 该 workspace 的会话中：

WSL workspace 里会隐藏 Windows PowerShell 工具；普通 Windows workspace 不受影响。

安装与启用¶

从 DSH 的 Plugins 页面安装本地目录，或者用命令安装：

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

仓库里只有 TypeScript 源码。安装本地目录前先执行 npm ci（会自动构建）或 npm run build。通过 GitHub 安装时构建由 prepare 触发；如果 pnpm 阻止了构建脚本，按安装器提示在对应 profile 的 pnpm-workspace.yaml 里放行那个确切的包键后重试。也可以执行 npm pack，安装包含编译产物的 tarball。

也可以在会话里让 agent 用插件管理器安装该目录。link: 只保证目录中的文件可读，不保证正在运行的 Host 会重载代码。默认配置下，Host 侧代码改动需要完全退出并重启 DSH，浏览器侧改动只需刷新页面。DSH 默认 HMR 配置是 root: []，只监听配置文件。如果退出提示说有正在运行的任务，等它结束再重启。

另外，运行要求 Node >= 24.9.0（见 package.json 的 engines），对 @deepseek-ai/cordis 的 peer 依赖是 >=4.0.5 <5。

配置项¶

在 profile 的 cordis.patch.yml 里覆盖插件行的 config：

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

文件变更与交付卡片¶

发布前，WSL write / edit 会先进入官方 fs/write-intent / fs/edit-intent，让 DSH 抓到编辑前内容，成功后记录 fs/observed。工具结果复用原生 write/edit 的输出格式、元数据与 diff 呈现；官方 workspace-changes 会在回合结束时生成修改文件列表和对比。只读、越界、未观察、版本过期的写入仍然会被拒绝。

present 继续使用官方执行器和 deliverables/presented 事件，插件把 Linux 绝对路径、相对路径、~/、挂载盘路径转换成 Windows 可访问的路径，保留描述、文件数上限、普通文件校验和点击预览/打开行为。指向其他发行版的 UNC 路径会被拒绝。

修改文件列表会自动汇总文件工具成功改动的内容；单独的文件卡片仍由模型调用 present 发出，插件不会为每次源码改动自动发卡片。如果文件只通过 bash 改动，非 Git 目录缺少文件工具的预抓取，需要单独卡片时应显式让模型调用 present。

实现要点¶

入口占用官方 workspace 组件声明的两个单例槽位：sidebar.workspaces.directoryFlow 和 conversation.hero.workspace.directoryFlow，渲染自己的 Local folder / Connect WSL 选择器，priority 比官方占用者低，对话框画在 shell.overlay。选择 Local folder 时调用官方 ctx.uiWorkspace.pickDirectory()（或桌面端注入的 __DSH_DIRECTORY_PICKER__），原生选择行为不变。

Host 侧路由：GET /dsh-remote-wsl/{status,distros,warm,list} 和 POST /dsh-remote-wsl/connect，均为同源 JSON，拒绝跨站请求，默认只允许 loopback；connect 通过官方 workspaceRegistry.create() 注册 workspace。目录浏览直接走 \\wsl.localhost 共享，共享拒绝访问时回退到发行版内执行 find。终端包装官方 subprocess.spawnTerminal，仅当 cwd 落在 WSL workspace 内时替换 argv，其他终端原样透传。

适用场景与注意事项¶

适合 Windows 10/11 + WSL2 上开发、且项目实际在 Linux 侧构建和运行的用户，想让它以当前 dsh 进程权限运行：插件的 Host 路由、subprocess 调用都以启动 DSH 的账户权限执行，remote: true 还会把路由暴露给非 loopback 客户端，开启前需要确认网络边界。

安装前应先检查源码与许可证（MIT），确认它调用的 wsl.exe 子命令和网络路由与你的部署环境相符。插件当前在社区目录标记为未验证（status: unverified），仓库 1 颗星，属于早期项目，接入生产流程前建议先在隔离环境试运行。

结尾¶

dsh-remote-wsl 解决的问题很具体：让 DSH 的 workspace、终端和 agent 工具都落在 WSL 发行版一侧，而不是在 Windows 和 Linux 之间手工切换。目录页：https://www.skillhub.cn/plugins/MFJip612/dsh-remote-wsl ；源码与文档：https://github.com/MFJip612/dsh-remote-wsl 。