空白会话移交 OahzOb/dsh-blank-handoff

dsh-blank-handoff

一个 DeepSeek Harness 插件。关掉标签页再连接，界面会说「上一个会话被占用」——这个插件把这句话去掉。

它做什么

每次连接都会起一个自己的 dsh web，各有各的端口。浏览器打开其中一个时，会挑一个工作区，并倾向于复用一个空白会话——也就是没人说过话的那个——而不是再建一个新的。这个倾向本身是好的，但也正是「接管遗留会话」的来源：上一次连接建的那个空白会话还在磁盘上。

如果上一次连接的服务器还在跑，它就仍然握着这个会话的写租约，Host 会以 session/writer-held 拒绝。随包发布的客户端会新建一个会话来恢复，但它是靠抛异常恢复的，所以这个拒绝会传到对话里，你会看到：

当前会话已被占用，可能是其他正在运行的 DSH 导致的（如其他 dsh web、桌面端），请退出其他正在运行的 DSH 后重试。

这句话不成立。空白会话就是没人用的会话。

装上这个插件之后，这个拒绝会被静默移交给一个新会话，那句话再也不会出现。

它刻意不改什么

对于一个真正在用的会话，这个拒绝是真实的，也一直保持真实。要触发移交，必须同时满足：

- 请求里带了一个具名会话——这正是「接管」的含义；
- 错误码是 session/writer-held；
- 失败信息里点名的就是同一个会话；
- 这个会话不是对话当前选中的那个。

重新打开你正在看的那个会话、然后被拒绝，仍然会照常报出来。只有「没人在用这个会话」的情况才会静默处理。

安装

plugin_manager install_bundle target: github:OahzOb/dsh-blank-handoff

插件管理器也接受仓库 URL、.tgz、注册表名称，或者指向某个 checkout 的绝对路径。它会把依赖写进配置档，并把名字加进 dsh.profile.bundles——这两步都重要，装了但没进 bundle 列表的包完全不起作用。

客户端那一半随页面加载，所以已经打开的页面会一直保持随包发布的行为，直到重新加载。

验证它是否生效

客户端那一半会在页面上留一个计数器，因为插件的控制台输出不是可靠的渠道：

globalThis.__dshBlankHandoff // { installed: boolean, handedOff: number }

重新加载后 installed: false 说明 Sessions 服务始终没出现，随包发布的行为没被改动。handedOff 记录这个修复触发过多少次。

相关

发现这个问题的 Android 客户端：dsh-tabs-android——一个手机客户端，通过 SSH 连接其他机器上的 Harness 实例。

dsh-blank-handoff（中文）

一个 DeepSeek Harness 插件。关掉标签页再连接，界面会说「上一个会话被占用」——这个插件把这句话去掉。

它做什么

每次连接都会起一个自己的 dsh web，各有各的端口。浏览器打开其中一个时，会挑一个工作区，并倾向于复用它找到的空白会话——也就是没人说过话的那个——而不是再建一个新的。这个倾向本身是好的，但也正是「接管遗留会话」的来源：上一次连接建的那个空白会话还在磁盘上。
如果上一次连接的服务还活着，它就仍握着那个会话的写租约，于是 Host 以 session/writer-held 拒绝。官方客户端其实能自愈（它会新建一个会话），但它是先抛错再自愈，所以这个拒绝会冒到对话里，让你看到：

当前会话已被占用，可能是其他正在运行的 DSH 导致的（如其他 dsh web、桌面端），请退出其他正在运行的 DSH 后重试。

这句话是不成立的 —— 空白会话就是没人用的会话。

装上这个插件之后，这种拒绝会被静默地转交给一个新会话，那句话不会再出现。

它刻意不改的部分

会话确实在被使用时，拒绝是真实的，也依然是真实的。触发转交需要同时满足：

- 请求里指名了某个会话（这正是「接管」的特征）；
- 错误码是 session/writer-held；
- 错误指的就是那个会话；
- 那个会话不是当前对话选中的那个。

你主动重开正在看的会话而被拒绝，仍然会照实报错。只有「没人在用」这种情况才是静默的。

安装

plugin_manager install_bundle target: github:OahzOb/dsh-blank-handoff

插件管理器也接受仓库 URL、.tgz、包名，或磁盘上的绝对路径。它会把依赖写进 profile，并把包名加进 dsh.profile.bundles —— 两样都要：装了但不在 bundle 列表里，等于什么都没做。

客户端半边随页面加载，所以已经打开的页面在下一次刷新前仍是旧行为。

怎么确认它在工作

客户端半边在页面上留了一个计数器（因为插件的 console 输出不是可靠通道）：

globalThis.__dshBlankHandoff // { installed: boolean, handedOff: number }

刷新后 installed: false 表示没等到 sessions 服务、行为未被改变；handedOff 是它生效过的次数。

相关

发现这个问题的安卓客户端：dsh-tabs-android —— 在手机上通过 SSH 连接其它机器上的 Harness。

工程记录

下面这些章节只有英文，承载的是上面摘要没有的细节：每个故障是什么、从哪来、修复又是怎么验证的。
两者重叠的地方，摘要回答的是会发生什么；这里回答的是为什么会这样。

它修的问题

每条连接都跑自己的 dsh web，用自己的端口、自己的 token。
浏览器打开其中一个服务时，会挑一个 Workspace，然后对这个 Workspace 优先复用一个空白会话 —— 也就是没人在里面说过话的会话 —— 而不是再建一个空的。这个偏好本身是好事，可它也正是残留会话被接管的原因：上一次连接建出来的空白会话还在磁盘上，于是下一次连接就试着接管它。

如果上一次连接的服务还在跑，它就仍握着这个会话的写租约，Host 便以 session/writer-held 拒绝。官方客户端能恢复 —— 它会新建一个会话 —— 但它是靠抛错恢复的，所以这个拒绝会冒到对话里，显示成：

当前会话已被占用，可能是其他正在运行的 DSH 导致的（如其他 dsh web、桌面端），请退出其他正在运行的 DSH 后重试。

这句话是不成立的。空白会话就是没人用的会话，转交出去谁也不会损失什么。在桌面客户端自己的流程里，它表现为：关掉一个标签页，再连一次，就被告知上一个会话被占用了。

来源记录如下：

| 部分 | 位置 |
| 那句话 | @deepseek-ai/dsh-client-ui-conversation → error.sessionInUse |
| 它依据的错误码 | session/writer-held，由 @deepseek-ai/dsh-api-session-controller 抛出 |
| 谁抛出它 | 来自会话写租约的 SessionAlreadyOwnedError（内核锁，按会话目录） |
| 谁触发它 | @deepseek-ai/dsh-client-ui-workspace → reuseOrCreateBlank → reuseBlank |
| 错误的恢复方式 | reuseBlank 捕获 session/writer-held，然后创建新 Session 后重新抛出 |

它改变了什么

在 ctx.sessions.create 外面包一层。当一次指定了 Session 的创建因 session/writer-held 失败时，它不带 id 重试——新建一个 Session——然后返回那个。拒绝永远不会到达 Conversation。

它刻意不动的东西

对于真正正在使用的 Session，拒绝是真实的，也保持真实。只有在以下条件全部成立时才转交：

- 请求指定了 Session（sessionId）——这正是 adoption 的含义；
- 失败是 session/writer-held；
- 失败信息在给出 Session 时，指向的是同一个 Session；
- 那个 Session 不是 Conversation 已选中的那个。请求重新打开你正在看的 Session 却被拒绝，仍然必须上报。

非空白的 Session 永远不会走到这条路径：只有空白 adoption 会在没人查看时按 id 请求 Session。

已验证

在隔离的 sandbox 配置档中验证（DSH_HOME 指向临时目录，--patch overlay 挂载这个确切的文件），两个真实的 dsh web 服务器，两个真实的 Chrome 连接，观察网络流量：

[two] api/session/create ok=false code=session/writer-held ids=session-3ed0cf64-…
[two] CONSOLE: blank-handoff: session-3ed0cf64-… is held by another connection; opened a fresh blank Session instead (1 so far) [two] api/session/create ok=true code=undefined ids=session-ccff8ef3-…
[two] PLUGIN MARKER: {"installed":true,"handedOff":1}
connection 2 reported "in use": false

拒绝仍然发生在网络上——如果没发生，这个测试就毫无价值——而页面从不报告它。对话落在一个全新的空白 Session 中。

可观测性

客户端那一半在页面上保留一个计数器，因为插件的 console 输出不是可靠的通道：

globalThis.__dshBlankHandoff // { installed: boolean, handedOff: number }

页面重新加载后 installed: false 意味着 Sessions 服务在五秒内从未出现，发布的行为未被改动。

安装

插件是一个 bundle，所以通过插件管理器安装，而不是手动安装——配置档依赖加上 bundle 选择，才能让这一行挂载：

plugin_manager install_bundle target: github:OahzOb/dsh-blank-handoff

插件管理器接受 GitHub 简写（github:owner/repo）、仓库 URL、.tgz，或注册表名称。它也接受磁盘上某个 checkout 的绝对路径，开发期间就是这样安装的。

这会把 "dsh-blank-handoff": "link:<path>" 写入配置档的 dependencies，并把名称追加到 dsh.profile.bundles。两者都重要：依赖让包可解析，bundle 条目让它的补丁层挂载。一个已安装但不在 bundle 列表中的包完全不起作用。
已在运行中的服务器上确认，不是从安装过程推断出来的：

include:blank-handoff moduleName dsh-blank-handoff enabled: true fiberPhase: active

Client 那一半随页面一起加载，所以已经打开的页面会一直保持出厂行为，直到重新加载。

如果 install_bundle 报 'pnpm' is not recognized

这个失败看起来像插件问题，其实不是：机器上的 pnpm 坏了，它会挡住所有插件的安装。值得记住这一点，因为诊断信息有误导性。两种故障，都在实际环境里见过：

1. 入口指向了已删除的目录。 %LOCALAPPDATA%\pnpm\bin\pnpm.cmd 引用了 global\v11\<hash>\node_modules\@pnpm\exe\pnpm.exe，这是一个 junction，指向某个从 %TEMP% 安装、后来被删掉的包。可执行文件本身还在 pnpm 自己的 store 里，位于 node_modules\.pnpm\ 下；把 .cmd 指向那个路径就修好了，不用重装任何东西。
2. harness 的 PATH 里含有字面文本 %PNPM_HOME%\bin，从未展开，于是 pnpm 被到一个叫这个名字的目录里去找。这一条更隐蔽：长驻进程会保留启动时的环境，所以在 shell 里修好 PATH 传不到它那里。修法是在一个本来就在 harness 的 PATH 上的目录里放一个 pnpm.cmd shim。

看插件之前，先用 pnpm --version 检查一下。

目录结构

| 文件 | 作用 |
| index.js | Host 那一半 —— 惰性，存在只是为了让 bundle 挂载、Client 模块加载 |
| client.js | 全部修复内容：ctx.sessions.create 包装 |
| cordis.patch.yml | Bundle 层：一行插件记录 |