Two desktop-app (0.2.0-rc.2) bugs: BOM written into profile package.json crashes boot; turn resume after interrupted tool call crashes with 'prepare' undefined

[ThreeBody6666]

Two reproducible bugs on DSH Desktop 0.2.0-rc.2 (Windows 11, electron 44, node 24.18.1):

1. Boot crash: BOM written into profile package.json

readProfileManifest crashes with:

SyntaxError: Unexpected token '', "{\n    \"n\"... is not valid JSON
    at readProfileManifest (dsh-app-boot/lib/index.js:835)

The affected profile's package.json was valid before, then started failing — the file had been rewritten with a UTF-8 BOM prefix (U+FEFF). JSON.parse rejects the BOM, so every subsequent boot of that profile dies until the BOM is stripped by hand. I hit this twice on 2026-10-01 and again on 2026-10-03 on the same profile (desktop), which suggests something in the app rewrites the profile manifest with a BOM-prefixed writer.

Fix: strip the BOM before JSON.parse (or never write one) — JSON.parse(text.replace(/^\uFEFF/, '')).

2. Turn resume crash: Cannot read properties of undefined (reading 'prepare')

In a long-running desktop session (84 turns / 543 steps, 12 subagents), a host restart interrupted two running tool calls (the session correctly records them as interrupted, result unknown, and injects the recovery prompt). After that, the turn fails with:

本轮运行失败: Cannot read properties of undefined (reading 'prepare')

This is not persisted in the session artifact (v4 jsonl) and produces no host crash log — it fails silently on the turn-resume path. Subsequent messages in the same session keep failing the same way, so the session is effectively stuck. A clean host restart + new turn may or may not recover it; a brand-new session works.

Suspect: the turn-resume path (agent/session prepare) dereferences something that is undefined when the previous turn ended mid-tool-call. Might already be reworked on master — mentioning it here for the rc.2 desktop build.

Happy to provide the affected session artifacts or more diagnostics if useful.

— ThreeBody6666

[yuxu4468-hash]

补一份同根因的实测（DSH 桌面端 0.2.0-rc.2 / Windows 11 / profile desktop）。

「插件页读不出来」和「清单带 BOM 启动即崩」是同一个函数。 readProfileManifest（@deepseek-ai/dsh-app-boot/lib/index.js:835，裸 JSON.parse(raw)、不剥 BOM）不只走启动路径：@deepseek-ai/dsh-plugin-manager 直接 import 了它（dsh-plugin-manager/lib/index.js:10，:227/:239/:425/:460/:616/:626 都在调）来做 bundle 列表。所以 BOM 存在而应用已经在运行时，先坏的不是启动而是插件页：

POST /api/pluginManager/listBundles
{"ok":false,"error":{"code":"gateway/internal",
 "message":"Unexpected token '', \"{\r\n    \"n\"... is not valid JSON"}}

同一文件、同一宿主、不重启的单变量对照：

profiles/desktop/package.json	pluginManager/listBundles
带 UTF-8 BOM（EF BB BF）	ok:false — Unexpected token '' … is not valid JSON
剥掉 BOM（3 字节）	ok:true，返回 23 个 bundle

也就是说 readProfileManifest 里加一句 raw.replace(/^\uFEFF/, '') 可以同时修掉「启动即崩」和「插件页一直读不出来」（后者与 #7682 现象一致）。我这边发现时 BOM 还在，若先重启，那个 profile 就会按 #8574 描述的样子直接崩。

BOM 是谁写的（我这次不是 app）：那次重写唯一的语义变化是给 dependencies 与 dsh.profile.bundles 各加一个插件；留下的文件是 4 空格缩进、": " 双空格、值对齐（PowerShell ConvertTo-Json 风格），而 DSH 自己写这份清单是 JSON.stringify(manifest, undefined, 2) + "\n"（dsh-plugin-manager/lib/index.js:235）；写入前留下的备份无 BOM。与 #8574 的复现一致（PS 5.1 的 -Encoding UTF8 默认带 BOM）。

建议：在这一处剥离 BOM，并让报错点名「文件以 UTF-8 BOM 开头」——BOM 的来源可能是 PowerShell 5.1、某些编辑器或第三方安装脚本，用户不该靠猜（#6758 的论点）。