现在的dsh如果安装了一个问题插件，很容易就会导致dsh启动失败

[luceln]

之前安装了一个问题插件，直接把dsh搞崩了，想要卸载这个问题插件又比较麻烦。dsh有没有像手机的安全模式，直接关闭所有用户插件启动，方便用户卸载有问题的插件？

[aoaoms]

可能该插件侵入了框架底层文件导致启动加载插件即报错，无法进入平台。可以重装dsh 解决。我遇到过，似乎没有合适的调整方法。重装就好了。

[micean]

预留一个其他的软件就可以了，pi、opencode之类的，把启动错误信息丢进去就能修复了

[liyangbing]

先保留证据，再隔离问题插件

“重装 DSH”可能解决启动，但会同时破坏定位问题所需的 profile manifest、lockfile、插件目录、patch、凭据和 Sessions。更安全的临时方案是把诊断和修复分开：先复制或快照出问题 profile，记录版本、插件清单和第一条启动错误，再在独立的 recovery profile 或临时 DSH_HOME 中验证。

建议按这个顺序排查：
1. 先运行版本和配置转储，分别比较默认 Bundle、profile patch、home-level patch、lockfile 和插件依赖闭包。
2. 只隔离最近安装或最近变更的用户插件；不要一开始删除整个 home，也不要把干净测试 profile 整体覆盖回生产 profile。
3. 如果必须设计“安全模式”，应明确哪些用户插件可跳过、哪些 Host/身份/传输插件不能跳过，并在 UI 中显示 degraded 状态和被跳过的插件。
4. 修复后重新加载同一个 profile，确认插件清单、配置、凭据边界和一个已知 Session 都仍然可用，再清理临时证据。

这里有一份独立社区手册的对应恢复流程，包含 profile-scoped 快照、逐层隔离、无破坏诊断、失败回滚和验证门槛：Profile repair, reset, and plugin compatibility recovery。它不是 DeepSeek 官方文档；请以当前 DSH 版本的实际命令和源码为准。

[argszero]

查了 0.1.2-alpha.1 源码：dsh 目前没有手机式的一键"安全模式"启动开关（全树没有 --safe-mode / --no-user-plugins 之类的 flag），但已经存在三条不依赖 UI 的禁用/隔离路径，都可以在 dsh 启动失败时用文件操作完成：

路径 A — 单插件禁用（加载阶段失败时有效）
$DSH_HOME/profiles/<名字>/cordis.patch.yml 是每个 profile 的用户插件层（PROFILE_PATCH_FILENAME，app-boot/src/profile.ts:44），模板注释明确支持 "id-targeted config overrides, disables, and insert lists"。给问题插件加一条：

- id: <插件条目 id>
  disabled: true

启动审计 assertEntriesLoaded（app-boot/src/index.ts:674）把 disabled 条目视为唯一合法的无 fiber 状态——即使该插件模块解析失败也不会阻塞启动（"Disabled entries are the only valid fiber-less state"）。

路径 B — 条件禁用，一行实现"手动安全模式"
cordis.patch.yml 的 disabled 支持 !!js 表达式（user-patches.spec.ts 有专测：disabled: !!js process.platform === "win32"）。所以可以先写好：

- id: <插件条目 id>
  disabled: !!js process.env.DSH_SAFE_MODE === "1"

平时正常启动；出问题时 DSH_SAFE_MODE=1 dsh --profile <名字> 即以禁用该插件的状态进入，卸载后再恢复。这是现有机制里最接近"安全模式"的形态。

路径 C — 官方恢复诊断 + 手动零插件启动
--dump-default-config 是 bundles-only 恢复诊断：loadProfile(..., { userLayer: false }) 明确跳过用户层（profile.ts:800-801 注释："a bundles-only consumer … cannot fail on a broken user layer"）。手动等价操作 = 把该 profile 目录下的 cordis.patch.yml 改名或移走 → 以零用户插件启动 → dsh plugin --profile <名字> remove <包名> 卸载问题插件 → 还原文件。另外自定义 profile 从 DEFAULT_PROFILE_BUNDLES = ['@deepseek-ai/dsh-base'] 起步（profile.ts:162），即新建一个空 profile 天然就是"只有基础插件"的环境，也可以作为隔离舱。

真正的缺口（对应 aoaoms 说"只能重装"的深层原因）
启动审计 assertEntriesActivated（app-boot/src/index.ts:707/:799）是 fail-loud：如果插件在激活阶段抛错（ctx.on() 里 throw，而非解析阶段失败），boot 会 dispose 整个插件树并抛错退出——此时 disabled 豁免也救不了（豁免只覆盖 load 阶段）。不存在"跳过该插件、降级继续启动"的交互路径，所以问题插件一旦在激活期崩溃，用户确实会被锁在门外。若要实现真正的安全模式，最便宜的做法就是复用现有 seam：加一个启动 flag，让最终审计对用户层（cordis.patch.yml）条目跳过 assertEntriesActivated（bundle 层如 Host/身份/传输插件保持 fail-loud——与 profile 的 bundle 层/用户层分离天然对齐），启动后显示 degraded 状态并保证 dsh plugin remove 可达。这也是 @liyangbing 第 3 点（哪些插件不能跳过）在架构上的落点。