dsh-plumb-identity

DeepSeek Harness 将同一进程内的所有会话复用一条 plumb 连接，而 DSH 的 MCP 客户端在请求中不携带任何身份信息——既没有 per-conversation session id，也没有 _meta 标记。plumb 的隔离层（工作区分片、读跟踪、邮件寻址）依赖一个已声明的身份才能正确运作，未标识的会话会彼此强制重绑工作区。常见的补救是在 AGENTS.md 中要求每个会话自行声明 session_id，但 DSH 的 in-process 子代理没有父上下文，结构上就是匿名的，单靠指令管不住。

dsh-plumb-identity 在传输层解决这个问题。它监听 DSH 的 tools/execute 瀑布流，从 exec.agent 中提取调用者（主会话或子代理）的 session UUID 与 workspace，为每一次 plumb 工具调用铸造一个稳定的逻辑身份 id。随后，插件在 MCP SDK 的请求路径上为 plumb 调用自动注入 _meta 身份标记，并在每个 agent 的首次 plumb 调用时主动发出 session_start 声明，将工作区锁定、会话名记录到位。整条链路失败即静默放行：SDK 缺失、patch 被拒、声明被退回，调用照常完成，AGENTS.md 指令层仍作为兜底。

如果你用 DSH 同时跑多个工作区、多个会话并依赖 plumb 的 per-agent 分片做隔离，又或者经常用 in-process 子代理执行工具调用，这个插件能把身份从靠模型自觉变成靠传输层强制，彻底消除 pin-contest 和多工作区互相覆盖的问题。对单人多窗口调试和团队多 agent 流水线同样适用。