[修法分享] 桌面版升级后「工作区全部消失」：三层判别 + 可回滚的完整修复步骤（补充 #13385 / #13376）

[dongsheng123132]

本文不是重复报 bug，而是把一次完整自救过程整理成可直接照做、可回滚的修法。关联：#13385（旧核心包被 hoist 遮蔽）、#13376（升级迁移重新启用 bundle / 首启 sessionController 不可用）、#7637 / #6942 / #7256（前端 localStorage 快照损坏）。

一句话结论

数据层几乎从来没坏过。 「左侧工作区全部消失」最多由三层各自独立造成，先判层再动手，否则会像我一样把「前端状态修好了」误判成「没修好」，或者把「列表回来了」误判成「修好了」。

层	典型症状	判别	修法
数据层 storages/workspace.json	几乎不会是它	记录数、workspaceIds 与 tables.workspaces 是否对齐	别动它，别重装
前端状态层 Electron localStorage	整个左侧栏白屏 / 外壳都不见	dsh.workspace.view.v5 旧快照含 null	清该键 / 重建状态目录
依赖服务层（最常见）	侧栏外壳在、列表空；或「正在加载工作区…」一直转	host 日志 incompatible with dsh … + did not activate + waiting for service: storageDomain	把 profile 里的官方包整体对齐到宿主版本

这次是后两层叠加：清完前端状态只让「工作区」标题和搜索按钮回来，列表仍空；再处理依赖层才全好。

---

第 0 步：先别做这几件事

• ❌ 不要删 / 移走 workspace.json、sessions/，不要重装应用（数据一条没少，动它只会增加风险）。
• ❌ 不要指望「停用全部第三方插件」：我停过 7 个，现象不变；而且重启后 host 会把它们自动重新启用（与 [Bug] 桌面端升级迁移会把已禁用的可选 bundle 重新启用并与依赖安装竞态，首启 sessionController 不可用、无法新建会话 #13376 的迁移写回一致），这个动作根本不持久。
• ❌ 不要用 rm -rf 删 node_modules 里的官方包（[Bug] 升级后可选插件遮蔽核心包，导致 workspace/session 服务全部不可用，界面表现为"会话全部丢失"（数据实际完好） #13385 的临时绕过写的是删）。用 mv 移到备份目录，随时能回滚。
• ❌ 不要只移 @deepseek-ai/dsh-storage-domain 一个包。实测之后列表确实回来了，但点「新建会话」仍报 sessionController is unavailable——半死状态最坑人。

第 1 步：只读体检（先拿到版本对照）

# 宿主版本以应用包为准；Info.plist 是二进制 plist，不能按文本 grep
APPV=$(/usr/libexec/PlistBuddy -c "Print :CFBundleShortVersionString" \
  "/Applications/DeepSeek Harness.app/Contents/Info.plist")
echo "host = $APPV"
# 注意：dsh --version 可能还是旧版（我这边是 rc.1），不能当宿主版本用

# profile 里显式声明的官方依赖
node -e "const d=require(process.env.HOME+'/.dsh/profiles/desktop/package.json');
console.log(Object.entries(d.dependencies).filter(([k])=>k.startsWith('@deepseek-ai/')));"

# 被 hoist 到顶层的官方包，逐个看版本线
for f in ~/.dsh/profiles/desktop/node_modules/@deepseek-ai/*/package.json; do
  node -e "const d=require('$f');console.log(d.name, d.version)"
done

# 数据层确认还在（别动它）
node -e "const d=require(process.env.HOME+'/.dsh/storages/workspace.json');
console.log('workspaces =', d.global.workspaceIds.length, '| records =', Object.keys(d.tables.workspaces).length);"

前端状态层可顺手扫一下 leveldb 里有没有坏快照（macOS 路径，Windows/Linux 换成对应的 Electron userData）：

python3 - <<'PY'
import glob, os
D=os.path.expanduser('~/Library/Application Support/@deepseek-ai/dsh-desktop/Local Storage/leveldb')
b=b''.join(open(p,'rb').read() for p in glob.glob(D+'/*') if os.path.isfile(p))
print('v5 key:', b.count(b'dsh.workspace.view.v5'), '| groupExpansion:', b.count(b'groupExpansion'), '| bytes:', len(b))
PY

判读：只要 host 与 profile / hoisted 的版本线不一致，就是依赖层问题；did not activate 的行数就是被门禁拦下的官方包条数。

第 2 步：完整修法（全部可逆）

A. 先备份四样东西

TS=$(date +%Y%m%d-%H%M)
cp -p ~/.dsh/storages/workspace.json ~/.dsh/storages/workspace.json.bak-$TS
cp -p ~/.dsh/profiles/desktop/package.json ~/.dsh/profiles/desktop/package.json.bak-$TS
cp -p ~/.dsh/profiles/desktop/pnpm-lock.yaml ~/.dsh/profiles/desktop/pnpm-lock.yaml.bak-$TS
cp -a "$HOME/Library/Application Support/@deepseek-ai/dsh-desktop/Local Storage/leveldb" \
      "$HOME/Library/Application Support/@deepseek-ai/dsh-desktop/Local Storage/leveldb.bak-$TS"

B. 完全退出应用（Cmd+Q / 托盘退出，不是刷新页面），确认进程和端口都没了再动文件；运行中 host 会覆盖你的修改。

C. 前端状态层：封存而不是删除（等价于官方解法 localStorage.removeItem('dsh.workspace.view.v5')）

B="$HOME/Library/Application Support/@deepseek-ai/dsh-desktop/Local Storage"
mv "$B/leveldb" "$B/leveldb.disabled-$TS" && mkdir -p "$B/leveldb" && chmod 700 "$B/leveldb"

D. 依赖层：把「所有」版本不一致的 hoisted 官方包整体隔离（关键步骤）

python3 - <<'PY'
import json, glob, os, shutil
HOME=os.path.expanduser('~')
root=HOME+'/.dsh/profiles/desktop/node_modules/@deepseek-ai'
target=HOME+'/.dsh/backups/quarantine-'  # 自己加时间戳
host=os.popen('/usr/libexec/PlistBuddy -c "Print :CFBundleShortVersionString" '
  '"/Applications/DeepSeek Harness.app/Contents/Info.plist"').read().strip()
os.makedirs(target+'/@deepseek-ai', exist_ok=True)
for p in sorted(glob.glob(root+'/*/package.json')):
    d=json.load(open(p))
    if d.get('version') != host:
        src=os.path.dirname(p); dst=target+'/@deepseek-ai/'+os.path.basename(src)
        shutil.move(src, dst); print('moved', d['name'], d['version'])
PY

这一步我实际移走了 8 个 0.2.2-rc.2 的官方包（dsh-cua-bundle、dsh-storage-domain、dsh-typert-protocol、dsh-computer-use、dsh-cua、dsh-brand、dsh-atomic-write、dsh-experimental-cua-macos）。只移一个 storage-domain 时，host 日志里剩下的 7 行仍被判 incompatible，session-controller 继续卡在 waiting for service: workspaceRegistry。

E. 对齐显式依赖并补齐依赖树：把 package.json 的 dependencies 里全部 @deepseek-ai/* 改成宿主版本（我这边是 dsh-cua-bundle / dsh-subagent-claude-code / dsh-subagent-codex 三项），然后在外部终端执行：

cd ~/.dsh/profiles/desktop && pnpm install --no-frozen-lockfile

会问是否清空 node_modules，输 y。注意：这一步要真正删改上千个目录，在应用内终端 / 受限环境里可能被拦；从系统终端跑最稳。不跑也能用（宿主 app.asar 自带核心实现），只是依赖树不完整，下次装插件可能又带回旧版。

F. 重启应用。

第 3 步：验证（4 条，缺一不可）

1. 左侧工作区列表回来；
2. 历史会话回来；
3. 亲手点一次「新建会话」并成功 —— 这是最容易漏的一条，也是「只删一个包」和「真修好」的唯一区别；
4. 重启后 workspace.json 的 mtime 被正常更新（证明 storageDomain + workspaceRegistry 真挂上了），host 日志里 0 disabled / 0 pending。

回滚

# 依赖层：把隔离目录里的包整批移回 node_modules/@deepseek-ai/
# 前端状态：删掉新建的空 leveldb，把 leveldb.disabled-$TS 改回 leveldb
# 配置：用三份 .bak-$TS 覆盖回去

全程我没有删除任何数据文件，workspace.json 自始至终未改动。

---

几点补充观察（可能对定位有用）

• 同一机制已连续复发三次：rc.1 → rc.2 两次、rc.2 → rc.3 一次。每次宿主升一个小版本，profile 里显式依赖与 hoist 出来的传递依赖都会整体落后一代。
• dsh plugin allow-version / version-exemptions 这类 CLI 逃生口在我这台机器上不可用：dsh plugin --profile desktop ... → error: profile "desktop" is managed exclusively by the Electron application。（[Bug] Desktop update can drop third-party plugin registration and block recovery / 桌面版更新可能丢失第三方插件登记并阻塞恢复 #13374 在 Windows 上用 dsh plugin --profile desktop add 是成功的，可能是平台或 CLI 版本差异，别当成通用结论。）
• 兼容性门禁本身检测得很准，日志把不兼容包名和期望版本写得清清楚楚；问题在于检测到之后只禁用插件行，没给桌面用户一条能走通的「对齐依赖」路径，最后表现成「工作区全没了」。

给官方的三条小建议

• A 应用升级完成后，校验托管 profile 的 @deepseek-ai/* 版本线；不一致时提示并提供一次「对齐依赖并重装」（操作前备份 package.json / lockfile，失败可回滚）。
• B 让 desktop profile 至少支持只读的版本状态查询，或把修复入口放进插件管理器 UI / 提供「安全模式启动」。
• C 当 did not activate 导致核心服务（storageDomain / workspaceRegistry / sessionController）缺失时，给面向用户的明确错误提示，而不是让侧栏静默变空——现在这个表现和「数据全丢」完全无法区分，代价主要是恐慌和误操作。

环境

macOS / Apple Silicon，Desktop 0.2.2-rc.3（Info.plist），CLI dsh --version = 0.2.2-rc.1，profile desktop，storages/workspace.json 360 条全程完好。