[Proposal] 侧边栏 Browser 的存储分区应可持久化：第三方站点登录态每次 App 重启后丢失

[LyraWang6688]

TL;DR

右侧栏 Browser tab（Desktop / <webview>）的存储分区是进程内、每次启动随机的，因此任何需要登录的第三方页面（飞书文档、Notion、Linear…）在 DSH 重启后都必须重新登录。这让「在 DSH 里边看文档边干活」这个主要用法基本失效。

希望改成分区名可由 workspace 稳定派生、并加 persist: 前缀（或提供 opt-in 配置），保留按工作区隔离的语义不变。

环境

• macOS arm64（Apple Silicon）
• @deepseek-ai/dsh-desktop 0.2.1-rc.3，Electron 44.7.0，Node 24.21.0
• 桌面版，profiles 的 desktop profile

复现

1. 在右侧栏 Browser tab 打开任意需要登录的站点（例：https://<tenant>.feishu.cn/docx/...），完成登录；
2. 完全退出 DSH，重新启动；
3. 重新打开同一个 URL。

实际：落在登录页，需要重新扫码/登录。
期望：仍在登录态（同一工作区）。

补充两个同进程内的观察（用户反馈，我这里只做到代码级定位，未在打包版内实测）：

• 新建会话后打开同一 URL，同样要求登录；
• 关闭右侧栏的终端 tab 再打开后，Browser tab 里的站点也可能要求重新登录。

根因

Desktop 主进程在 will-attach-webview 之前为 guest 分配分区（编译产物 lib/main.js，region lib/types/browser-guests.js，DesktopBrowserGuests.acquire()，shipped main.js 第 10501 行附近）：

let partition = this.partitions.get(workspace);
if (partition === void 0) {
  partition = `dsh-sidebar-browser-${randomUUID()}`;
  this.configureSession(session.fromPartition(partition));
  this.partitions.set(workspace, partition);
}

两个问题叠加：

1. 没有 persist: 前缀 → Electron 给的是 in-memory session，cookie / Web storage / cache 都不落盘。
2. 分区名里带 randomUUID()，而 partitions 只是主进程内的 Map → 每次 App 启动都产生全新的分区身份，等于一台新浏览器。

而 client 侧其实已经算出了一个稳定的存储身份（ui-sidebar-browser/lib/client.js）：

return workspace === void 0 ? `session:${sessionId}` : `cwd:${workspace.path}`;

这个 key 在同工作区内是稳定的，但被上面那个随机 UUID 抵消掉了。

包的 README 已把这点列为 known limitation：「Desktop 按规范化的工作区 CWD 共享进程内存储分区……Cookie 与 Web storage 不跨应用重启保留。」

为什么用户无法自行绕过

• 本包没有插件配置字段（dsh-client-ui-sidebar-browser 的 Config 为 absent），没有任何开关能改成分区持久化；
• ui-chat.linkOpening 只决定「点链接用侧边栏还是系统浏览器」，与登录态无关；
• 从外部改 app.asar 不行：Contents/Info.plist 里有 ElectronAsarIntegrity，改文件会被完整性校验拦下，同时破坏签名、并被自动更新覆盖。

所以这只能作为产品层取舍在上游改。

提案（最小改动）

const suffix = createHash("sha256").update(workspace).digest("hex").slice(0, 32);
partition = `persist:dsh-sidebar-browser-${suffix}`;

要点：

• 隔离语义不变：仍然是一个工作区一份分区，工作区之间互不可见；只是这份分区从内存搬到磁盘。

• 提交/释放 guest 的语义不变：release() 现在只销毁 guest、明确保留 workspace storage，正好与持久化一致。

• 建议复用已有的 cleanStorage(browserSession)（平台登录 webview 里已经在用）作为「清除该工作区浏览数据」的入口，给介意 cookie 落盘的用户一个出口。

• 如果担心默认行为变化，可以做成 opt-in：

  - id: ui-sidebar-browser
    config:
      storagePersistence: none | workspace   # 默认 none，保持现状

  用户显式开启后上面的 persist: 才生效。个人更希望默认就是 workspace——因为「在侧边栏持续使用某个站点」是这个 tab 的核心价值，而每次重启重新登录几乎让这个价值归零。

需要一并考虑的边界

• cookie 落盘后是普通 Chromium cookie store（…/Application Support/@deepseek-ai/dsh-desktop/Cookies），UI 上最好有一句说明；
• 登出仍由站点自己控制，DSH 不做 cookie 生命周期管理；
• 若第 2 个观察（同进程内关闭终端后也掉）成立，说明 in-memory session 还可能随最后一个 webContents 销毁而被回收；持久化可以顺带覆盖这个场景。

验收标准

1. 打开需登录站点并登录 → 完全退出 App 并重启 → 同一工作区重新打开该 URL：仍是登录态；
2. 关闭该 Browser tab、再重新打开同一 URL：仍是登录态（不依赖 guest 是否存活）；
3. 切换到另一个工作区打开同一 URL：不是登录态（隔离仍在）；
4. 未登录过的站点 / 新工作区：行为与现在一致（走一次登录）；
5. linkOpening=sidebar 的链接点击路径不受影响。

相关

• 现有文档已把该行为记为 known limitation，本提案是希望把它变成可配置项；
• 相关但独立的一个 bug（不影响本提案）：0.2.1-rc.3 在本机出现过多次启动即崩，DesktopHostFatalError: cannot create effect on inactive context（installDesktopUpdateTaskControl），崩溃会额外放大「登录态丢失」的体感。如需要我可以另开一贴附日志。