[Feature Proposal] Desktop: pick the startup Profile, and boot a clean one when a Profile breaks

[CC19990113]

Motivation

The Electron desktop shell can only ever boot one Profile, and the only first-aid path it offers destroys the user's composition. Two gaps, both visible from the released code.

1. The Profile is hard-coded

apps/desktop/src/paths.ts:

export function resolveDesktopPaths(dshHome: string = resolveDshHome()): DesktopPaths {
  return {
    profile: join(dshHome, 'profiles', 'desktop'),
    lock: join(dshHome, 'profiles', 'desktop', 'lock'),
  }
}

There is no selection surface anywhere. In the released 0.2.0-rc.2 macOS bundle (app.asar/lib/main.js) the strings DSH_DESKTOP_PROFILE, --profile and profileName occur zero times, and DSH_DESKTOP_DSH_DIR only applies to an unpackaged launch. The CLI refuses the Profile as well (rejectElectronProfile), so a user cannot reach it from outside either.

2. Recovery is destructive

apps/desktop/src/project-manager.ts:

async disableAllPlugins(): Promise<string | undefined> {
  return this.withLock(() => sanitizeProfile('dsh', this.paths.profile, WEB_PROFILE.bundles))
}

sanitizeProfile renames cordis.patch.yml to a .bak-<ms> sibling and replaces the bundle list with the web template's bundles (const WEB_PROFILE = PROFILE_TEMPLATES.web) — not the desktop Profile's list. So the fatal-error recovery dialog costs the user their entire composition, and what it restores is the wrong template. When a tree fails to mount, there is no way to boot a clean environment and inspect the damage: the options are "disable everything" or hand-edit files outside the app.

Why this matters for the plugin ecosystem

Writing plugins is one of the participation paths CONTRIBUTING points at, and #8317 already documents the distribution half of this boundary — a plugin that needs its own composition never reaches the official desktop entry point, because installation targets the running Profile. This is the boot-side twin: even when a working Profile already exists on disk, the desktop shell cannot be told to start it, and if the current one breaks, the shell's own recovery throws the composition away.

Prior art in the ecosystem

anywhere-labs/dsh-desktop v2.0.17 (MIT, same @deepseek-ai/dsh 0.2.0-rc.2 runtime) ships exactly this in dsh-plugin-desktop:

• src/profile-manager.ts — "Desktop-owned profile discovery and restart-safe selection state"
• src/profile-service.ts — list(): DesktopProfileSummary[] and "Persist one validated Profile for the next startup."
• src/tray-locale.ts — the tray shows Profile：${profileName}
• src/profile-preferences.ts — preferences scoped to one Profile
• src/desktop-boot-recovery.ts — injects an action into the framework-free boot page: 打开恢复模式 / Open Recovery Mode, with the guidance "…你可以进入恢复模式卸载有问题的插件，或新建 Profile 后重新启动。/ …Open Recovery Mode to uninstall the affected plugins or create a new Profile, then restart DSH Desktop."
• src/safe-mode.ts — DESKTOP_SAFE_MODE_PROFILE_NAME = 'desktop-safe-mode' plus a launcher-owned disposable home: "Isolated Harness home; Safe Mode never reads the normal DSH data directory", removed on exit

Grepping this repository for an equivalent turns up nothing (safe mode, recovery mode, DESKTOP_SAFE → no runtime hits).

Behavior

Smallest useful version first:

1. Startup Profile selection. The desktop shell can be told which Profile under $DSH_HOME/profiles/* to boot. The choice persists and applies on the next start; the default stays desktop, so single-Profile users see no change.
2. Profile list. Before starting anything, the shell lists candidate Profiles with availability — missing manifest, bundles skipped for a DSH peer mismatch (the existing skippedBundles report), no web-capable surface.
3. Non-destructive recovery. When boot fails, the failure page offers (a) start with a clean/empty Profile, and (b) a recovery surface that can disable the specific offending plugin — without overwriting the user's dsh.profile.bundles.
4. Isolation. Whatever recovery environment is used must not read or write the normal data roots (sessions/, storages/, skills/, credentials): a disposable home, removed on exit.
5. No silent composition rewrite. If the existing disableAllPlugins() path is kept, it should restore the desktop Profile's template list rather than PROFILE_TEMPLATES.web.

I am not asking for a multi-Profile console. A launcher flag plus a choice on the boot-failure page would already cover the reported problem.

---

中文摘要

官方桌面壳（0.2.0-rc.2）只能启动一个写死的 Profile（apps/desktop/src/paths.ts → $DSH_HOME/profiles/desktop），发布包内 --profile / DSH_DESKTOP_PROFILE 这类字符串出现次数为 0，CLI 侧又被 rejectElectronProfile 拒绝；而启动失败时唯一的官方自救手段是破坏性的：disableAllPlugins() → sanitizeProfile(..., WEB_PROFILE.bundles) 会把 cordis.patch.yml 改名备份，并把 bundle 列表重置成 web 模板（不是 desktop 模板），用户自己的组合就此丢失，且无法先起一个干净环境查看损坏原因。

社区已有可行先例：anywhere-labs/dsh-desktop 2.0.17（MIT，同一 @deepseek-ai/dsh 0.2.0-rc.2 内核）的 dsh-plugin-desktop 实现了 Profile 发现与重启安全的选择状态（托盘显示当前 Profile、每个 Profile 独立偏好）、启动失败页的「打开恢复模式」入口，以及一个不读正常数据目录的一次性隔离环境（Safe Mode，desktop-safe-mode）。本仓库中检索不到对应实现。

期望：桌面壳支持选择启动 Profile（持久化，默认仍是 desktop，老用户无感）；启动失败页提供「用干净 Profile 启动」与「进恢复模式单独禁用出问题的插件」；恢复环境与正常数据目录完全隔离；若保留 disableAllPlugins()，请恢复 desktop 模板而非 web 模板。不需要多 Profile 控制台，一个启动参数 + 失败页选项即已覆盖该问题。

---

相关：#8317（[RFC] 插件市场与 dsh profile 设计，同一 profile 边界的分发侧）

[wilsonwangdev]

+1. A concrete manifestation from plugin install docs: dsh plugin --profile desktop add <pkg> fails with profile "desktop" is managed exclusively by the Electron application. Users following a normal CLI install guide hit a dead end. Even without profile selection, the error could name the in-app plugin page, and the docs should distinguish desktop (app-managed) from web/tui (CLI-managed).