DSH 的 Web 界面只监听 127.0.0.1，CLI 也拒绝 --host 0.0.0.0。这个设计是对的——它能把远程代码执行能力锁在本机。代价是：想在一台远程服务器上干活，你得自己在「文件在哪」和「终端在哪」之间来回搬。dsh-remote 就是补这段的：由你主动连出去，把远程目录变成 DSH 里的一个真实工作区。
项目在 GitHub 上 162 星（本站快照 159），MIT 许可，JavaScript 写的，2026-08-14 建仓、2026-10-19 还有提交。本站登记「已验证」，在 dsh 0.2.1-rc.2 下做过真实安装。它的 npm 周下载是 4,478，这个数字包含 CI 与镜像，不等于本站安装量。
它到底改了什么，没改什么
最关键的一句写在 README 里：不改动 dsh-workspace 官方代码，全部作为普通插件实现。
所以它的做法不是「劫持终端的 cwd」，而是：
1. 你保存若干台 SSH 机器的连接信息；
2. 在「选择工作区」时切到「远程」页签，浏览远端目录；
3. 插件创建一个真实的本地镜像目录，让 harness 正常收养它；
4. 之后用 SFTP 维持镜像与远端同步。
从 DSH 的角度看，这是一个普通的本地工作区；从你的角度看，文件其实在远端。
为什么「镜像」这个设计值得说清
很多人第一反应是「为什么不直接操作远端文件」。答案是 DSH 的一整套工具是围绕本地工作区建立的：文件引用、资源预览、会话 cwd、终端，都假设文件在本机。要让它们都认得远端，只有两条路——改核心，或者造一个本地镜像。
dsh-remote 选了后者。代价是一个必须知道的边界：镜像不是实时的。远端改了文件，本地镜像不会自动变，要 rw_sync。反过来，本地改了要不要回推，取决于 autoPush（默认 false，即不自动推）。
这个边界会造成一个典型误判：@ 能列出远端文件，但你用内置的读文件工具打开却是空或不存在。原因就在这里——@ 走的是插件自己的远端索引（fileReference），内置工具读的是本地镜像。读远端内容要用 rw_read_file，或者先 rw_sync。
接入的四个真实步骤
第一步：加机器，并且「设为当前」。 保存只是备用连接，只有「设为当前」或 Agent 调 rw_connect，才进入会话的 remote context。这一步不做，后面所有 rw_* 工具都不会有用。
第二步：体检。 设置页里的「远端 dsh 体检与部署」，体检部分是只读的：报平台、node、npm、dsh 版本、原生模块能否启动、代理与 npm 源。可以随便点，不写任何东西。
第三步：需要时部署。 如果体检判定「需要且可以自动装」，才会出现部署按钮。它把 dsh 装到远端私有目录（默认 ~/.dsh-remote/dsh），不写系统目录、不改 PATH、不覆盖你在用的版本——删掉那个目录就是完全回滚。默认装 0.1.5-rc.2，README 说这是第一个能在 Linux 上起 web 的版本。
第四步：选工作区，然后干活。 到这一步，rw_list_dir、rw_read_file、rw_edit、rw_exec、rw_search 才有意义。
remote context 是会话级的
这一点决定了它不会污染本地工作。只有当前 session 的工作区是某个远程镜像时，system prompt 才注入「Remote workspace」段落；普通本地会话完全不受影响，模型也不会主动去调 rw_*。
好处是干净，代价是每个新会话都要重新选一次工作区。如果发现自己「昨天还好好的，今天工具全都不动了」，先看会话的工作区是不是掉回本地了。
远程界面：不开端口也能看
README 里有个细节值得单独说：远端的 dsh web 可以当成本机的一个页面打开，而且远端不用开放任何端口。
做法是本机 SSH 连过去，在远端只监听 127.0.0.1 起一个 dsh web，再把端口经隧道搬回本机的 loopback（起始端口 3088，占用则顺延）。地址带一次性令牌，本机用它换 30 天签名 cookie，然后跳到干净的 /。
这里有两个必须知道的点：令牌地址不要外发；「断开」只关隧道，不会杀掉远端进程——要连进程一起停，用「断开并停止远端」，而且它只结束由本次插件启动的那个进程。
安全这件事，README 说得很直白
原文是：把凭据交给插件，等于允许 Agent 以你的用户身份在该主机执行 shell 命令，只添加可信机器。
这句话不是免责声明，是使用前提。配合两个默认值一起看更清楚：auditLog 默认 true（每条命令记进 $DSH_HOME/remote-workspaces/audit.log），hostKeyMode 默认 accept-new（首次信任，可选 verify）。前者建议保留，后者在受控环境里建议改成 verify。
还有一条容易忽略：密码默认存本机文件，勾选「加密保存」才会走 macOS 钥匙串 / Windows DPAPI / Linux secret-tool，后端不可用时回退明文。也就是说「勾了加密」不等于「一定加密」，得看你机器的凭据后端是否可用。
一次真实接入的结论
它解决的是一类很具体的需求：你有一台长期在跑的机器，代码在那儿，你想用 DSH 的界面和模型去改它，但不想把代码拉到本地、也不想在远端开端口。
它不解决的是：真正在远端跑的终端。DSH 侧栏终端的 PTY 来自全局唯一的 subprocess 服务，cwd 取会话工作区（远程会话就是本地镜像），插件既不能替换也不能重定向。想要远端终端，用「远程 DSH 界面」，或者 rw_exec 加 pty: true。
总结
dsh-remote 的思路是「反方向连出去 + 本地镜像 + 原生工作区」，因此能不改核心就接入远端；代价是镜像要手动同步、终端仍在本地。想对照同类插件的中文清单与安装形态，见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：有一台长期在线的开发机、想用 DSH 直接改远端代码的人；不想在远端开放端口的运维场景；需要把远端目录当工作区、又不想放弃本地预览能力的人。
不适合：只想跑一条远程命令的人（用 ssh 更省事）；期待「远端终端直接出现在侧栏」的人；不能接受手动 rw_sync 这一步的人。
标签：dsh-remote、DeepSeek Harness、远程工作区、SSH、SFTP
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。