[Bug][Desktop][macOS] rc.5：profile patch 被重写时丢失手写的 insert 条目，MCP 服务器静默消失

[9vn2nfzvt5-lgtm]

【缺陷报告】DSH 重写 profile patch 时静默丢弃手写的 insert 条目 —— MCP 服务器整体消失且无任何提示

建议标题：[Bug][Desktop][macOS] rc.5：profile patch 被重写时丢失手写的 insert 条目，MCP 服务器静默消失
建议标签：bug / desktop / macOS / mcp / data-loss（配置丢失，非崩溃）

一句话：配置丢了不会报错，只会让工具凭空消失——用户能看到的只有 unknown tool。

一、摘要

DSH Desktop（0.2.1-rc.5）在崩溃恢复流程里会重写
~/.dsh/profiles/desktop/cordis.patch.yml。重写后，文件里手写的 - insert: 条目整段消失，
而该条目正是本机唯一一处 MCP 服务器（@deepseek-ai/dsh-mcp-client）配置。

后果：宿主不再 spawn MCP 子进程；会话里该服务器下的工具全部变成 unknown tool；
没有任何错误、日志或界面提示（因为没有配置，就没有"启动失败"可报）。
用户重启应用、重启系统、更换会话都不可能恢复——只有手工改配置文件才行。

二、环境

项	值
应用	@deepseek-ai/dsh-desktop 0.2.1-rc.5（/Applications/DeepSeek Harness.app）
系统	macOS 27（darwin arm64）
Electron / Node	44.7.0 / 24.21.0
界面语言	zh-CN
配置文件	~/.dsh/profiles/desktop/cordis.patch.yml
相关插件	@deepseek-ai/dsh-mcp-client（包内存在，版本随安装）

三、现象

1. 会话里调用 MCP 工具，全部返回 unknown tool：

   Error: unknown tool "mcp__iphone__status"
   

2. ps aux | grep mcp_server.py 没有子进程；pgrep -f "--mcp" 也为空；
3. 重启应用 / 重启系统 / 反复重启 MCP 均无效；
4. 崩溃日志（~/Library/Logs/DeepSeek Harness/crash-*.log）里没有任何 MCP 相关记录；
5. 手工用 stdio 直连同一命令，initialize + tools/list 立刻返回 39 个工具——服务本身完全正常。

四、时间线与证据

本机的真实事故（时间均为本地时区）：

时间	事件	证据
11-04 16:48–16:50	启动连续崩溃 5 次（与本缺陷无关的 cookie 堆积问题，另案）	5 份 crash-*.log
16:50:42	点击崩溃对话框的「禁用第三方插件、备份 profile patch 并重启」	生成 cordis.patch.yml.bak-1793782242745（文件名的毫秒时间戳正好是 16:50:42）
—	该备份内容 1394 B，包含完整的 - insert: iphone-mcp 段	见 §五
17:24	清 cookie 后应用成功启动	cordis.patch.yml 的 mtime
17:24	同一文件变成 661 B，insert 段消失，只剩 3 条 UI 插件配置	wc -c / grep
18:54	首次调用 MCP 工具	unknown tool

关键点：备份与当前文件的差集，正好就是那段 - insert:。也就是说
恢复动作"备份了旧文件、然后写入了不含用户条目的新文件"，用户条目被静默丢弃。

五、配置片段（README 可复现的最小样例）

崩溃前（备份里，1394 B）：

- id: ui-chat
  name: "@deepseek-ai/dsh-client-ui-chat"
  config: { transcriptView: standard }
# …
- insert:
    - id: iphone-mcp
      name: "@deepseek-ai/dsh-mcp-client"
      config:
        serverName: iphone
        transport: stdio
        command: /Users/jianghui/Documents/XIAO ESP32S3 Plus/.venv/bin/python
        args:
          - /Users/jianghui/Documents/XIAO ESP32S3 Plus/control/mcp_server.py
        env:
          HIDBRIDGE_BASE: http://127.0.0.1:8890
        failOnStartupError: true
        toolCallTimeoutMs: 60000

崩溃恢复后（661 B）：上面 - insert: 整段不存在，其余 3 条 UI 条目保留。

六、建议的复现步骤（给开发）

1. 在 cordis.patch.yml 末尾加一条无害的 - insert:（任意插件 id）；
2. 记录文件大小与 grep -c "insert"；
3. 触发一次「禁用第三方插件、备份 profile patch 并重启」（或任何会重写该 patch 的路径）；
4. 对比：insert 条目是否还在；若不在，观察：
   • 有没有任何日志 / 弹窗 / 设置页提示；
   • .bak-* 备份是否生成（本机生成了，说明备份逻辑存在，但写入是覆盖式而非合并式）。

七、根因分析（推断与依据）

• 依据 1：备份文件（1394 B）与事故后文件（661 B）的差异恰好是用户的 insert 条目；
• 依据 2：备份文件名是毫秒时间戳，指向恢复动作的执行时刻（16:50:42）；
• 依据 3：正常启动不会重写该文件——同样的 insert 段从安装期一直存活到事故当天（多日、多次启动）；
• 推断：恢复/设置写入路径用「按内部模型重建整份 patch」的方式写文件（replace），
  只序列化它认识的条目；无法识别的 insert 列表被丢弃，且没有 diff 校验、没有告警。

请重点检查 cordis.patch.yml 的全部写入点（恢复对话框、设置保存、插件启停），
确认哪些是 replace、哪些是 merge。

八、影响

• 影响面：所有在 profile patch 里手写 insert 的用户——MCP 服务器、自定义插件条目都算；
  而当前 build 没有 MCP 设置界面（包内只有 dsh-mcp-client / dsh-mcp-resources，
  没有 ui-settings-mcp），所以 MCP 只能手写在 patch 里，等于全部用户都在风险面内；
• 严重度：配置静默丢失 + 无任何提示 + 重启不恢复 + 只有改文件才能救；
• 可发现性：极差。用户看到的是「工具没了」，会先怀疑模型、网络、MCP 服务端，
  实际是本地配置被吃掉了。本机从首次报错（18:54）到定位（00:55）跨了约 6 小时、一次会话重启。

九、建议修复

A（必须）：重写时合并而不是覆盖
读取现有文件 → 按 id 合并内部模型 → 保留所有无法识别的条目 → 再写回。
若实现成本高，至少对 insert 列表做「原样保留」这一条。

B（必须）：写入前后做 diff 校验
新内容的条目数/条目集合若是旧内容的真子集，视为异常：要么保留旧条目，要么中止写入并报错。
最省事的实现：写前 cp 一份 .bak-<ts>（本机恢复动作已有此行为），
写后比较 insert 条数，少了就回滚 + 记录一条 WARN。

C（强烈建议）：让"0 个 MCP 服务器"可见
启动时若 mcpServers 为空，在日志与设置页明确显示「未配置任何 MCP 服务器」。
现在的行为是"什么都没发生"，这是本缺陷最难查的部分。
failOnStartupError: true 只能覆盖「spawn 失败」，覆盖不了「条目根本不存在」。

D（建议）：给 MCP 一个正式设置页
现在用户必须自己发现 cordis.patch.yml 在哪、格式是什么，还要自己承担被重写覆盖的风险。

十、临时缓解（用户侧，已验证）

# 检查
grep -q iphone-mcp ~/.dsh/profiles/desktop/cordis.patch.yml || echo "MCP 配置丢了"

# 补回（先备份，再追加，最后做 YAML 校验；不合法自动回滚）
tools/ensure-dsh-mcp.sh

脚本（本机自用，无公开仓库）：核心就四步——检测关键字 → cp 备份成 .bak-<epoch> →
追加模板段 → yaml.safe_load 校验，不合法就 cp 回滚。恢复后需重启宿主才生效。

十一、附：另一个独立缺陷

本次事故的诱因是启动崩溃（dsh-auth-* cookie 无限累积 → 请求头超 16 KiB → 431 →
desktop welcome: Web authentication failed），已另行整理，与本缺陷无因果关系：
即使没有那次崩溃，只要用户点一次恢复动作，配置就会丢。

—— 提交者：macOS 用户，DSH Desktop 0.2.1-rc.5

[Muguett-DBY]

对照了 rc.5 的源码，补充一个和修复方向有关的细节：恢复动作没有解析 YAML 再筛掉 insert。Desktop 调用的 sanitizeProfile 会把整份 cordis.patch.yml 重命名为带时间戳的备份，并把清单中启用的 bundle 列表重置为内置默认值；已安装的依赖和清单的其他字段保留。之后 initProfile 发现 patch 不存在时会新建空模板。

这能解释备份中的 insert 为什么不再处于活动配置里，但仅凭这段源码还不能确定你在 17:24 看到的 661 B 文件具体是由哪次写入生成的。

恢复方案的设计记录 提到，坏掉的 patch 或其中插入的插件本身可能导致启动失败，所以恢复时把整个 patch 移出启动路径。也就是说，直接自动合并所有旧条目可能会把导致崩溃的配置带回来；不过，恢复后让用户更容易发现和找回配置，确实值得改进。

你已经从备份找回了 MCP 配置；如果之前还通过其他 bundle 启用了第三方插件，也可以检查一下它们的启用状态。另外，yaml.safe_load 能检查 YAML 语法，但不能保证 patch 的结构或插件启动一定正确。备份可能包含凭据，保留在本地即可。

以上是按 rc.5 源码和现有测试核对的，没有在你的桌面环境里复现。

[9vn2nfzvt5-lgtm]

复核：661 B 不是空模板 —— 删除发生在恢复动作之后的第三次写入

回帖用。2026-11-06，针对上游按 rc.5 源码给出的说明做的现场复核。
结论：rename / 重置 bundle 列表这两条完全对得上；「之后 patch 是空模板」这条不成立。
这会把修复的落点从 sanitizeProfile 挪到另一个写入路径上。

感谢对照源码 —— 你说的三件事里有两条，本机留下的文件可以直接印证，先确认：

预测	本机证据	判断
只做重命名，不解析 patch	应用生成的那两个 .bak-*，mtime 都还是 10-19 10:43:2x（原 patch 的最后修改时间）；cp 会刷新 mtime，rename 不会	✓
清单里的 bundle 列表被重置	package.json mtime = 11-04 16:50:42（点恢复那一刻），内容 [dsh-base, dsh-web-app]，与 WEB_PROFILE.bundles 一致	✓
恢复不解析 patch 内容	661 B 与 1394 B 的 diff 只有删除、零改动	✓，但不是恢复动作删的（见下）

代码侧也对上了：@deepseek-ai/dsh-app-boot/lib/index.js 的 sanitizeProfile()（renameSync +
writeProfileBundles）、initProfile() 的 PROFILE_PATCH_TEMPLATE，桌面端调用点 lib/main.js:3586
this.withLock(() => sanitizeProfile("dsh", this.paths.profile, WEB_PROFILE.bundles))。

一、661 B 不是模板，是「子集」

• 模板是 3 行注释 + []，217 B（本机 ~/.dsh/profiles/web/cordis.patch.yml 是从没动过的活样本）。
• 661 B 是 1394 B 的真子集：删掉 ui-settings-general、agent-default-model、整段 insert，共 733 B，
  其余字节一字不动；保留的 3 条还带着用户值（step: done、completion: api-key、transcriptView: standard）。
• 661 B 的 mtime 是 17:24，比恢复动作（16:50:42）晚 34 分钟 —— 恢复若只留下空模板，这一版内容无从产生。

所以时间线应是三段，不是两段：

16:50:42  恢复动作：rename patch → .bak-1793782242745（并重置 package.json 的 bundles）
17:24     启动：initProfile 发现 patch 不在 → 写 217 B 空模板
17:24     应用按自己的设置模型把「它管的那几项」写回 patch → 661 B（insert 是外来条目，不在模型里，就此消失）

旁证：本机后来手工恢复的 1097 B（661 B + insert）在 11-05 14:30 应用启动过一次之后 mtime 未变
→ 这个重建写入只在 patch 缺失/为空的首次启动触发，不是每次启动都写。

二、对修复落点的影响

• A（合并而非覆盖）方向对，但要挪位置：sanitizeProfile 不删东西（它只改名），删的是那次重建写入。
  要改的是「按设置模型重建 patch」这条路径 —— 按 id 合并、insert 原样保留。
• B（写前后 diff）同样要挪过去，判据用 entry id 集合（新内容 id 集合是旧的真子集即异常），比条目数准。
• C（让「0 个 MCP 服务器」可见）不变，仍然是最值钱的一条：这次卡了 6 小时，卡的就是「什么都没发生」。
• 缩小排查范围的线索：661 B 保留了模板开头三行注释，所以写者不是
  CordisLoader.write() → yaml.dump(root.data)（那会丢注释），而是文档级编辑（保留注释）。
  本机 grep 下来，cordis.patch.yml 只在 app-boot/lib/index.js、桌面端 lib/main.js 和
  dsh/lib/profile-boot-*.js（后者只有注释）里出现，写者可能并不直接提这个文件名（路径来自配置），
  建议顺着「保留注释的 YAML 文档编辑」去找。

三、下次复现时怎么指认这个写者

stat -f '%m %z' ~/.dsh/profiles/desktop/cordis.patch.yml
sudo fs_usage -w -f filesystem | grep cordis.patch.yml    # 谁在写，进程名直接给出来

或者复现前把 patch 设成只读（chmod 444）：写入报 EACCES 的调用栈就能直接指认模块。
（本机这次没抓到，事后才想明白——时间戳能定位「什么时候」，定不了「谁」。）

四、你们问的两件事

• 第三方 bundle 的启用状态：没有要复查的。本机 dependencies: {}、profile 目录下没有 node_modules
  （pnpm 装过必然留下），bundle 只有 dsh-base / dsh-web-app 两个内置的；唯一的第三方条目就是那段手写
  insert。
• 备份里的凭据：三份 .bak 与现 patch 里只有 HIDBRIDGE_BASE，无 token/密钥；报告里的路径是本机路径。

另外补一条你们提的「让用户更容易发现和找回」：备份文件名只有毫秒时间戳，界面上应有一句
「profile 曾被重置，有备份可恢复（<时间>）」并给一键还原 —— 现在的状态是备份躺在目录里没人知道。

—— 2026-11-06 复核

[Muguett-DBY]

你补充的几个值指向 rc.5 的桌面引导。账号未登录、检测到已有 API Key 且引导尚未完成时，它会依次保存聊天偏好（ui-chat 的 transcriptView: standard、performanceUsage: detailed）、开发者工具开关（ui-settings 的 enabled: true），最后写入 ui-settings-account 的 step: done、completion: api-key。触发条件 · 写入顺序

我用这版引导逻辑和配置编辑器做了内存对照。从 217 B 空模板开始，三次保存会写出这些设置并保留模板注释。把相同的保存操作跑在已有手写 insert 的样本上，insert 也保留了。设置编辑器读取当时的活动文件，按 id 修改，并跳过 insert 行。编辑器代码

如果 661 B 的三个 id 正好是上面这些，可以优先对照这条启动路径。我的对照使用了模拟设置和文件读写，你那次实际写入的进程仍需现场记录确认。编辑器用的是原子写入，抓取文件事件时可以同时看 profile 目录里的临时文件和重命名。

[aturzone]

核对过源码与设计记录后，结论是：这不是「重写 patch 时漏掉 insert」，而是崩溃恢复动作的既定行为，但你的观察揭示了一个真实的可用性缺口。

机制（rc.5 源码路径）
崩溃对话框的「禁用第三方插件、备份 profile patch 并重启」在 Host 关闭后调用共享的 sanitizeProfile（packages/boot/app-boot/src/profile-sanitize.ts，设计记录 .agents/notes/implemented/architecture/2026-09-15-desktop-native-fatal-recovery.md）：它把整份 cordis.patch.yml 重命名为 cordis.patch.yml.bak-<epoch-ms>[-序号]，不解析该文件，然后把 bundle 列表重置为内置默认值并重启。下一次启动时 initProfile 发现 patch 不存在，创建一个空 patch。所以：

• 你的 1394 B 备份里完整保留了 - insert: iphone-mcp 段；
• 当前 661 B 文件是「新建空 patch + 之后设置写入的 3 条 UI 条目」；
• 手写 insert 条目随之移出活动配置，但并没有被「合并式写入」丢掉——它在备份文件里；
• 恢复的目的本身就是停用第三方行，所以不会自动回填；
• 没有配置就没有 MCP 启动失败，因此没有错误日志，只表现为 unknown tool。

立刻恢复的办法

ls -l ~/.dsh/profiles/desktop/cordis.patch.yml.bak-*
# 方式一：只把备份里的 - insert: 段追加回当前文件
# 方式二：若事故后没有再改过 UI 设置，直接整份覆盖回去
cp ~/.dsh/profiles/desktop/cordis.patch.yml.bak-<时间戳> ~/.dsh/profiles/desktop/cordis.patch.yml
# 重启 DSH

（注意：整份覆盖会丢掉恢复后新增的 3 条 UI 条目；只拷 - insert: 段更稳。）

文档与真正的缺口
apps/desktop/docs/diagnostics/README.md 第 28 行描述了「重命名整份 patch、下次启动创建空 patch、已安装包和旧备份保留、Electron console 记录备份路径」，但没有明确说明「手写条目也一起失效、不会自动恢复、重启后没有应用内提示」——这正是你这次踩到的信息缺口。我准备了一个 docs 分支补这一点：
https://github.com/aturzone/deepseek-harness/tree/docs/recovery-handwritten-rows（`065f580075`）

更值得修的是产品面：恢复成功后应用内应有一次可见提示（备份路径 + 已停用内容 + 一键查看/恢复备份），而不是只写 Electron console；或者在执行恢复动作前明确告知「手写条目会失效」。源码上这需要在恢复时写一个 marker，下次启动 ready 后消费一次并展示。若维护者认可这个方向，我可以出 patch 草案（marker + 一次性通知 + Plugins 页入口）；仓库 PR 通道关闭，只能分支形式供 cherry-pick。

[Muguett-DBY]

手动恢复那一步补个边界情况。先退出 DSH 再编辑配置。如果重启后还没保存过设置，活动 patch 可能仍是带注释的 [] 空模板，这时需要把 [] 替换成备份里的 - insert: 列表。直接在文件末尾追加会让 YAML 解析失败。当前文件已有 - id: 列表时，可以把 - insert: 放在同一顶层列表里。

我用 rc.5 的解析函数和锁定的 js-yaml 4.3.2 做了内存对照。空模板后直接追加会报 end of the stream or a document separator is expected，替换 [] 和往已有列表追加都能解析。恢复说明里可以带上这个细节。空模板 · 解析入口