新版本更新的时候，经常会有跟插件的冲突导致启动不了。所以能不能变成保障本体启动，有冲突的插件自动禁用？

[DragonOxTale]

如题

[xiaoyuyu6420]

这个诉求社区已经从几个方向提过了，串一下方便推动官方：#5242（插件出问题不该拖垮主程序，同样的建议）、#5216（有人直接写了"自动禁用失败插件"的启动脚本）、#5106（插件加载缺故障隔离，一个插件挂全树倒）。加上你这个，说明是普遍痛点。

官方实现之前，升级翻车时的自救姿势（#5860 楼里刚验证过的判别法）：

1. 最小 profile 启动：只留 @deepseek-ai/dsh-base + @deepseek-ai/dsh-web-app、不带任何第三方插件，对着真实数据跑——如果会话能正常列出和选择，就是某个第三方插件和新版本不兼容，不是数据或本体坏了。
2. 锁定并移除：确认是插件后逐个加回（最近更新过的优先怀疑）。紧急时直接编辑 ~/.dsh/profiles/web/package.json 删掉它的依赖行再 dsh plugin --profile web install 救急——profile 只是插件的运行环境，怎么动都不碰 ~/.dsh/sessions 里的会话数据。

[DragonOxTale]

现在都是靠隔壁agent修

[argszero]

这个诉求跟 #5864（插件 import 一个 bundled core 没有的导出 → 整个 profile boot 崩溃 + crash-loop）是同一根因的两面，值得一起看。按 master d347e70390 源码，当前 boot 对插件失败是故意 fail-loud 的：

• packages/boot/app-boot/src/index.ts:692 assertEntriesLoaded —— 任何非 disabled 条目没有 fiber 就直接抛："plugin(s) failed to load: ...; Cordis startup failed"；
• 同文件 assertEntriesActivated —— loader 树 settle 后，任何一个 enabled 条目 import 失败 / 激活 rejected / 停在 pending，就抛 N entries did not activate（带原始堆栈），然后进程退出。

也就是说今天没有任何"本体先启动、插件失败只禁自己"的路径——一条插件失败 = 整个 app 不启动。这个设计对开发期是对的（作者需要立刻知道自己的插件坏了），但对终端用户是灾难性的：升级把不兼容插件拉进来 → 启动即崩 → 用户只能手工编辑 cordis.yml 把 entry.disabled 设 true（assertEntriesLoaded 尊重 disabled，所以这是今天唯一的逃生口）。

建议的修复形状（三层）

1. 策略分层：把"fail-loud"从无条件改成可配置——开发/CLI 默认保持 loud（诊断价值不能丢），用户 profile（尤其 desktop app / 自动升级场景）走 resilient 模式：插件失败 → 该 entry 自动置 disabled + 把错误写进可见的启动报告（插件生态诉求：官方侧边会话渲染面 / 快照字段稳定性承诺 / 只读权限 preset #5859 说的"移除信号"），本体继续 boot。
2. 自动禁用写入：disabled 是写配置状态，loader 里已经有 dedupe/reconcile 先例（同族 [Bug] plugin install reports success but silently disables an unresolved profile bundle #1377/`dsh plugin add` re-registers plugins already loaded by `cordis.patch.yml`, crashing web boot with `duplicate loader entry id` #2889 的 dedupe-by-id + clone 修复），"失败 → 写 disabled:true + 原因"是同一个机制面的扩展。关键是不动用户的其它配置。
3. 一次性 vs 持久：建议自动禁用只对"启动时 import/激活失败"生效，且记 quarantine（失败清单 + 时间），避免静默永久禁用把好插件也关掉（[Bug Report] Seeded / forked sessions fallback to workspace name after restart (cached title skipped during cold listing) #5857 那种用户手工 enable 找回的场景）。

现状逃生口（升级遇冲突时今天就能用）

plugins:
  entry:
    <冲突插件名>:
      disabled: true

assertEntriesLoaded 会放过 disabled 条目，本体能起。等插件作者修好再改回。这个手动路径同时也是自动化的语义基础。

插件面判定：boot 策略（何时问、谁被禁、怎么报告）是 core loader 层的决策点，插件无法在 loader 之前运行来救自己——缺口在 core，插件是受害者（#5864 已证）。但确认后插件可以承接 UX 侧：启动报告渲染、quarantine 清单 UI、一键 re-enable（像 #5861 那种小 core UI + 插件补强）。维护者若认可 resilient 方向，这个和 #5864 的 per-entry fail-soft 是同一份 diff 的两个面。