web 打开其他进程写入的会话时会被接管：显示冻结、F5 无效，并存在双写风险 | Web attaches sessions owned by another process: frozen display, ineffective F5, double-writer risk

[RGarvel]

现象

两个 dsh 进程共享同一个会话文件时（例如：IM bot 跑在独立 profile/进程，用户在 dsh web 里查看该会话）：

1. 在网页里打开该会话时，web 进程会向会话文件写入一条 session/end-seed——即 web 把它 resume/接管 了；
2. 此后 session.history 一直从 web 进程的内存快照提供，外部进程写入磁盘的新事件永远不出现；
3. F5 无效；重启 web 能一次性看到最新，但再次打开又被冻结；
4. 更危险：如果用户从网页端对该会话发消息，web 的 agent 与外部进程会同时写同一份日志，极易损坏。

分析

• historySourceFor 优先 attached：只要 ctx.sessions.get(sessionId) 命中，就不再读盘；
• 打开会话会触发 agent 作用域的查询型 RPC（如 session.models 等）走 agent resolver 的"冷会话 resume 一次"逻辑，把会话挂进本进程——只读浏览也产生了接管副作用；
• 缺少跨进程所有权概念：web 无法知道这个会话正被另一个进程活跃写入。

建议

1. 查询类 RPC 免接管：session.models、重命名预览等只读查询应能在不 resume 的情况下从日志/头部读取；
2. history 磁盘优先降级：attached 会话若无运行中 turn 且磁盘 revision / 事件数领先于内存，改从磁盘读（或至少提示已过期）；
3. 跨进程会话只读标记：识别出"非本进程写入"的会话，GUI 上禁用 prompt 输入（或明确警告双写风险），避免用户无意中触发损坏。

临时规避

把 IM 插件直接装进 web profile（dsh plugin --profile web add …），让 bot 与 web 同进程、单写入者——显示即实时。已在 QQ bot 场景实测可行。