前言¶

2026 年，DeepSeek Harness (DSH) 依然是智能体开发中常用的本地化工具。当使用 dsh --profile web 启动 Web GUI 进行管理时，开发者通常只能通过浏览器查看工作区状态，缺乏直接在本地环境交互的能力。dsh-workspace-native-open 作为一个客户端插件，通过注入菜单项解决了这一痛点，让 Web 界面能够直接触发宿主机的文件操作。

核心功能¶

该插件仅在通过 loopback 地址访问 Web GUI 时生效。在 DSH 的工作区行点击 ⋯ 菜单，会新增三个本机动作：

1. 在文件资源管理器打开：调用系统文件管理器（explorer.exe / open / xdg-open）。支持 WSL 路径的自动翻译。
2. 在终端打开：在工作区目录启动新终端窗口。Windows 优先探测 pwsh，其次为 powershell；WSL 路径会经过 wslpath 翻译后交由 Windows 控制台打开；其他平台使用 $TERMINAL。
3. 在 Code 打开：直接尝试打开目录。插件不检测 VS Code 是否安装，点击后静默忽略失败情况。WSL 下优先使用 Linux 侧的 code 脚本。

此外，插件具备以下特性：

• 安全性：仅对 localhost、127.0.0.1、::1 以及内建放行的 dsh.localhost 显示菜单。远程访问或非白名单 Host 头的请求会被拒绝。
• 静默运行：失败时不打扰用户，但所有请求、探测结果和错误日志都会以 workspace-native-open 前缀写入 harness 日志。

安装¶

需要使用 Web profile (dsh --profile web)。通过官方命令安装：

dsh plugin --profile web add github:JoeyLearnsToCode/dsh-workspace-native-open

工作原理¶

插件分为宿主侧和客户端侧两部分。

宿主侧在 webServer 服务上注册了 POST /api/plugin/workspace-native-open 端点。该端点会校验 Host 头是否在白名单内，检查请求体长度和超时（413/408），并执行本机打开动作。为了安全，它强制 JSON content-type 并进行 CSRF 防护。

客户端侧通过订阅 webserver/index-inject 事件，向 index.html 注入脚本和样式。脚本在 loopback 域名下激活，通过观察 DOM 中的工作区菜单按钮（依赖 aria-label 识别）和其后的 portal 菜单（点击因果配对）来动态添加菜单项。菜单文案根据 <html lang> 和插件内联的翻译文件生成。

平台细节与注意事项¶

• Windows 终端：使用 where.exe 探测 pwsh 和 powershell。注意 Windows 10+ 必带 PowerShell，因此不再保留 cmd 兜底。Windows 控制台程序使用 Start-Process 且不能带 DETACHED_PROCESS，否则命令会静默退出。
• VS Code 安全：Node ≥ 20.12 拒绝直接 spawn .cmd shim（CVE-2024-27980）。因此 code.cmd 通过 PowerShell launcher 调用，插件因此不探测安装状态。
• WSL 行为：在 WSL 上点击「在终端打开」会在翻译后的 \\wsl$ 路径打开 Windows 控制台，这与文件资源管理器的行为一致。
• 自定义白名单：dsh.localhost 已内建放行。如需放行其他本地域名，需修改 src/index.ts 中的 LOOPBACK_HOSTNAMES 并重新构建。
• 日志：所有操作均以 workspace-native-open 为前缀记录日志，包括失败原因和退出码。

总结¶

dsh-workspace-native-open 是一个轻量级的 DSH 插件，通过 DOM 注入和宿主端点桥接，实现了 Web 界面与本地文件系统的安全交互。它适合需要在浏览器中管理本地开发环境的用户。

GitHub 仓库：JoeyLearnsToCode/dsh-workspace-native-open