[Bug] 0.2.1-rc.2：permission-presets × auto-review 环形死锁导致 permissions 投影永久丢失（附 32 键判据与可复现证据）

[Eviannaive1]

一、摘要

0.2.1-rc.2 上，会话一旦进入「工具全链失活」状态（cannot get required service "sessionProjections" in inactive context），重启宿主只能暂时缓解，无法根治。本文不复述 #9812 / #10007 / #10040 / #10041 已有的机制分析，而是补充三样它们没有的东西：

1. 一条独立可验证的判据：[Bug] 运行时重载导致权限选择器消失与工具永久失效：permission-presets 与 auto 预设的依赖死锁（0.2.1-rc.2 仍复现） #10040 提出的「投影缓存少 1 键、缺 permissions」在本机复现，并且区分出了哪些键数差异是正常的、哪些才是本病（见第三节，避免误判）。
2. 一次逐事件回放：从 /permission auto 到首个工具失败，间隔 8 秒，全过程无 turn/end、无 dispose（见第四节）。
3. 一个能在用户侧落地的规避手段：在 patch 层 disabled: true 关掉 auto-review，使 pinInitialPermission 永远不进入 preset === 'auto' 分支，故障前提消失（见第六节）。

没有修复，只有定位与规避。 版本核查见第二节：rc.2 之后上游零提交，master 上这三处仍在。

---

二、版本核查（2026-10-19）

项目	值
最新 Release	dsh-v0.2.1-rc.2，2026-10-17T08:16:33Z，prerelease: true
仓库最后一次提交	687f282e8，2026-10-17T07:22:43Z（Merge pull request #6408 … release-dsh-0.2.1-rc.2）
pushed_at	2026-10-17T08:16:09Z
本机 /dsh/package.json	@deepseek-ai/dsh-desktop-runtime 0.2.1-rc.2
rc.2 之后的新提交	0

发布序列：rc.2 / rc.1 / alpha.5 / alpha.4 / alpha.3 / alpha.2 —— 全部 prerelease，无 stable。

补充观察：@deepseek-ai/dsh-desktop、dsh-desktop-runtime、dsh-ops 在公开 npm registry 上 dist-tags={}、versions 为空，桌面版不走公开 npm。核心子包（dsh-session-projection / dsh-experimental-auto-review / dsh-hmr / dsh-app-boot）的 next 标签都停在 0.2.1-rc.2。

结论：无可更新版本。以下问题在 master（687f282）上依然存在。

---

三、判据：怎么确认「我中招了」

3.1 缓存位置与结构

~/.dsh/storages/session_projcache/sessions/<sessionId>.json

{"record":{"rows":{…}}}，rows 的键名即投影名。

3.2 检测脚本（Node）

const fs = require('fs');
const d = require('os').homedir() + '/.dsh/storages/session_projcache/sessions/';
for (const f of fs.readdirSync(d).filter(x => x.endsWith('.json'))) {
  const rows = (JSON.parse(fs.readFileSync(d + f, 'utf8'))?.record?.rows) || {};
  const n = Object.keys(rows).length;
  console.log(
    f.replace('session-', '').slice(0, 8),
    'keys=' + n,
    ('permissions' in rows) ? 'OK' : 'MISSING permissions',
    new Date(fs.statSync(d + f).mtimeMs).toISOString()
  );
}

3.3 ⚠️ 关键：不能只看「键数少了」

本机 38 个缓存文件的键数分布是 33×16 / 32×1 / 31×9 / 27×10 / 26×1 / 25×1。
如果按「比最大值少就是坏」去判断，会误伤 20 个正常文件。实测差异如下：

键数	缺的键	性质
33	—	当前完整插件组合的正常态
32	只缺 permissions	⚠️ 本病
31	dsh-memoir/activity、mnemonSubagentTokenUsage	正常，那两插件当时未启用
27	clearai checkpoints agentTeam costUsage mnemonSubagentTokenUsage dsh-memoir/activity	正常，10-17 及更早的旧组合
25 / 26	更早组合	正常

判据必须精确到「缺的是不是 permissions」。 这也解释了为什么 #10040 说「正常 28、故障 27」，而本机是「正常 33、故障 32」——同一个病，插件组合不同，绝对值不可移植，只有「唯一缺失项为 permissions」这个相对判据可移植。

3.4 本机实测

会话	键数	permissions	mtime (UTC)
session-4329d18b-…	32	❌ 缺失	2026-10-19T00:32:50Z
session-4395e445-…	33	✅	2026-10-18T11:42:57Z
session-a75a55d3-…	33	✅	2026-10-19T00:47:26Z
session-6858a321-…	33	✅	2026-10-19T04:22:12Z

全库 38 个文件中唯一掉键的就是 4329d18b，时刻落在当晚故障窗口（00:32）内。
该会话的 session.v4.jsonl.zstd 只有 1 行 / 197 字节，无法从日志侧还原，只能靠 projcache 时间戳定性。

附带一个现象：4395e445 / 6858a321 这两个曾经工具全死的会话，其缓存现在都是 33 键完整。说明故障解除后（同进程自愈或重启）投影会重新注册，缓存文件不是故障的持久证据，只有抓到故障发生时刻的那一份才有诊断价值。

---

四、逐事件回放（session-6858a321，最干净的样本）

10:16:06.963  tool/ptc-dispatch  pwsh   ok
10:16:09.156  command/run        {"name":"permission","args":" auto","source":{"kind":"user"}}
10:16:09.157  permission/preset  {"preset":"auto"}
10:16:09.158  sandbox/mode       {"mode":"danger-full-access"}
10:16:17.934  tool/call          run_code
10:16:25.266  tool/ptc-dispatch  ops_bash   ERROR   ← 切 auto 后第一个工具调用，8 秒后
10:16:46.259  tool/ptc-dispatch  compress   ERROR
10:17:44.829  tool/ptc-dispatch  read       ERROR
10:17:47.569  tool/ptc-dispatch  glob       ERROR
10:17:50.926  tool/ptc-dispatch  working_directory  ERROR
…
10:24:34.670  turn/end           {"turn":10,"reason":{"kind":"completed"}}   ← 僵尸态
10:37:05.754  turn/start         {"turn":11}
10:37:14.619  tool/ptc-dispatch  ×6 全 ERROR

关键点：

• 从 permission/preset 到首个失败仅 8 秒，中间没有任何 turn/end、没有 dispose、没有 config-reload 事件。
• turn/end 仍是 completed，不是 disposed —— 与 [Bug] Live sessions become permanently tool-dead and lose the permission picker: cannot get required service "sessionProjections" in inactive context, turn/end still reports completed #9812 / [Bug]回合运行中改模型/思维强度/权限，会让会话所有工具调用失效（sessionProjections in inactive context） #10007 一致。
• run_code 外层能跑，只有它内部的 tools.* 全死（PTC 桥不解析插件服务）。
• 下一个 turn 开新了，仍然全死，说明不是单个 turn 的问题。

三次故障会话的共同先决动作

会话	首次报错	故障前的设置变更
session-4395e445	10-18 19:02:06	12:35:17 /permission auto；12:36:13 切模型 + reasoningEffort: high
session-a75a55d3	10-18 19:01:46	首错前 29.8 秒 /permission auto；前 45.9 秒切模型
session-6858a321	10-19 10:37:14	10:16:09 /permission auto

三个故障会话全部执行过 /permission auto。这与 #10040 的「preset==='auto' 是必要条件」一致，也与 #10007 的「改模型/改强度也会触发」不矛盾 —— 二者都是「运行中重建 agent scope」的不同入口，而 auto 是最容易踩且后果最重的那一个。

一个反向观察（供维护者参考）

本机 session-a75a55d3 的 9 个故障段里，有 3 段（19:01 / 21:13 / 08:34）前 10 分钟内没有任何 profile 配置文件改动，而另外几段（22:26 / 22:50 / 23:19 / 00:41）前后有大量 .bak 写入。
→ 写配置文件既非必要也非充分条件，这一点与 #9812 里作者的对照实验（故意写两次 patch 未复现）相互印证。真正必要的是「运行中重建 agent scope」，配置文件只是其中一个入口。

---

五、机制（复述 #10040 并补充两条我们验证到的细节）

permission-presets 构造
  └→ 立即遍历 ctx.sessions.list() → pinInitialPermission()
      └→ 若某会话 preset === 'auto' 且 this.autoAdmit === undefined
          └→ throw 'permission: cannot restore preset "auto" without its active integration'
              └→ Cordis 事务回滚，注销刚注册的 permissions 投影
                  └→ Cordis 默认不重试抛异常的 Fiber
                      └→ auto-review 硬依赖 permissionPresets → 永远等不到 → 双双卡死
                          （⚠️ 这不是声明式的注入环，见下方「机制更正」）
                          └→ 宿主下发 snapshot 时缺 permissions
                              └→ 前端判空静默隐藏权限选择器
                                  └→ 旧会话绑定的 Context 变 inactive
                                      └→ 所有工具报 inactive context

机制更正（2026-10-19，据 @argszero 的源码级复核）

本文初版把这条链描述成「permission-presets ↔ auto-review 环形依赖」。这是错的，特此更正。

• permission-presets 的 inject 只有 ['shell', 'approval', 'sessions', 'sessionProjections']（src/index.ts:201），它完全不依赖 auto-review。
• 依赖是单向的：auto-review 在 src/index.ts:127 声明 inject = [... 'permissionPresets' ...]，是硬依赖。
• 所以环不在接线里，在失败里：permissionPresets 从未发布 → auto-review 永远 pending → registerAuto()（:721）永远不跑 → autoAdmit 永远 undefined → 那个 throw 的条件永远不清除。

真正的问题不是「抛不抛」，而是「从哪个调用点抛」。 同一个 throw 有两个调用点，炸伤半径完全不同：

调用点	位置	后果
A. session/created	:245-247	落在 publication announcement 内，packages/core/session/src/index.ts:45 明确「同步 throw 会否决并以配对 disposal 回滚」→ 会话被拒绝，服务本身无恙。这是有意设计，tests/permission-presets.spec.ts:300 专门保护它
B. 构造器遍历 ctx.sessions.list()	:248-250	此时已无可撤销的 publication。throw 拒绝不了任何东西，唯一可达效果是炸掉 permission-presets 自己的 fiber，并连带带走 11 行前刚注册的 permissions 投影

这也解释了本文第四节反复出现的「重启好像能修好」：冷启动时 list() 为空，走不到调用点 B。真正致命的是「存在活跃 Auto 会话时发生运行时 recompose」。

this.autoAdmit 唯一赋值点是 registerAuto()，全工程唯一调用者是 @deepseek-ai/dsh-experimental-auto-review；而 auto-review 又声明对 permissionPresets 的强依赖，在它构造完成前不会启动。

冷启动幸免的原因：ctx.sessions.list() 为空，循环不执行。
运行时重载必死的原因：只要内存里存在一个 preset === 'auto' 的活跃会话，就必然进入 throw 分支。

我们额外验证到的两点：

1. 同进程可自愈：a75a55d3 的故障段「最后一条错误 → 下一条成功工具」间隙实测为 444s / 1044s / 294s / 862s / 136s / 20s / 12s。所以「必须重启」是错误观察，重启只是恰好换了新进程。
2. 重启从来只是暂时缓解：该会话内用户明确说「重启了 / 重启好了」共 8 次（10-18 21:55 / 22:42 / 23:18 / 23:25、10-19 00:01 / 00:10 / 00:17 / 00:28），每次之后都再次复发。

---

六、用户侧规避（本机已实施，供参考）

在 patch 层停用 auto-review。

# ~/.dsh/profiles/desktop/cordis.patch.yml
- id: auto-review
  disabled: true

原理：auto-review 不注册，/permission auto 预设就不存在，pinInitialPermission 永远不会进入 preset === 'auto' 分支，那个 throw 不可能被触发。死锁前提消失。

代价：失去自动风险审查；/permission auto 从界面消失（这是预期行为）。
可正常使用 read-only / workspace-write / danger-full-access。

注意：hmr 若开启，改 patch 会立刻 reconcile；建议同时把 hmr 关掉，改完重启生效，避免「为了修 bug 而触发 bug」。

这条规避不能解决的

• 通过「运行中改模型 / 改 reasoningEffort / 启停插件 / 写 settings」触发的重建路径依然存在（[Bug]回合运行中改模型/思维强度/权限，会让会话所有工具调用失效（sessionProjections in inactive context） #10007 的主体）。
• 因此它只是掐掉最容易踩、后果最重的那条入口，不是通用解。

---

七、给维护者的具体请求

1. 把 reject 语义按调用点限定（而非全局取消 throw）：session/created 路径保留「发布前拒绝」；构造器 sweep（:248-250）改为记为 pending、不抛，待 registerAuto() 赋完 autoAdmit 后跑第二次 sweep 补齐。建议形状：pinInitialPermission(session, { reject: boolean })，session/created 传 true、sweep 传 false。这样 tests/permission-presets.spec.ts:300 仍然为绿。

2. 解耦加载时序：auto-review 对 permissionPresets 的依赖改 optional 或改为服务就绪事件异步注入，消除环形等待。
   （已撤回） 撤稿理由有两条：①这是单向硬依赖、不是注入环（见第五节「机制更正」），解耦破不了环；②依赖是真实的——auto-review 在 src/index.ts:678 读 ctx.permissionPresets，在 :689 / :721 / :729-730 调 registerAuto / current / set。把依赖改成可选只会把崩溃从构造器挪到 auto-review 的首次使用，而 autoAdmit 依旧永久 undefined。

3. 失败可见 + 可重试：vendor/include/src/index.ts:197-200 现在把 root.update() 的 rejection 吞成一条 warn（config update at … failed），被卸载的行永久保持卸载。建议失败行进入可见、可重试的状态。

4. turn 不应比 context 活得久（argszero 在 [Bug]回合运行中改模型/思维强度/权限，会让会话所有工具调用失效（sessionProjections in inactive context） #10007 提的）：backing fiber 被 unload 时，turn 应以具名原因结束，而不是报 completed 留下僵尸。

5. pinInitialPermission 里那处无保护的 this.autoAdmit() 需要一并加保护：:435 在没有任何 try 的情况下调用 autoAdmit()，而 auto-review 注册的 gate 按设计就会抛（src/index.ts:721-723：if (!accepting) throw new Error('auto-review: integration is closing')）。accepting 在 :726 置 false，与清 autoAdmit 的 :312-315 不是同一个 disposer，所以无论两者谁先析构，都存在一段「autoAdmit 仍注册但每次调用都抛」的区间。gate 会抛 × pin 无保护地调它 × throw 否决 publication，这个组合本身就是缺陷，与析构顺序无关。

6. 希望提供 host stderr 落盘/导出开关：0.2.1-rc.2 桌面版物理上无法拿到 config update at … failed / agent preset <id>: … 这几行（%APPDATA%\@deepseek-ai\dsh-desktop\logs\ 只有 crash-<time>-*.log，host stderr 存在 64KB 内存缓冲里，只在崩溃时落盘）。本机与 [Bug]回合运行中改模型/思维强度/权限，会让会话所有工具调用失效（sessionProjections in inactive context） #10007 的另一位报告者独立得到同一结论。若上游需要这三行来定位，目前只能先提供落盘开关。

---

八、我们能提供的

• 完整会话日志（session.v4.jsonl.zstd，多帧 zstd，可按需提供解析脚本）
• 掉键的 projcache 文件（session-4329d18b，32 键）
• 走查脚本：_marks.cjs（提取 model/selection、permission/preset、sandbox/mode 时间线）/ _win.cjs（事件窗口回放）/ _burst.cjs（故障段聚合）

需要哪一份可以直接说。

---

九、声明

• 本文为社区用户的本机复现与定位记录，不包含对上游代码的修改主张，也没有提交补丁。
• 我们核查过 master 687f282 的只读快照，确认 success-only cleanup、Auto bootstrap throw、danger-full-access teardown 三处仍在；这不是对已发布修复的验证。
• 涉及 [Bug] 运行时重载导致权限选择器消失与工具永久失效：permission-presets 与 auto 预设的依赖死锁（0.2.1-rc.2 仍复现） #10040 评论者 lanslot4n93r 的方案时，我们只作引用，未声称其补丁可解决本文全部症状。
• 修订记录（2026-10-19）：初版把该链描述为「环形依赖」，并请求「解耦加载时序」。据 @argszero 在讨论区的源码级复核，环不在接线里而在失败里，该请求已撤回；请求 (1) 已按调用点限定；新增请求 (5)（:435 无保护调用）与对 (6) 的补充（buffer 从不 flush）。本机结论（判据、回放、规避）不受影响。

---

附录 A · English Summary（供非中文维护者）

Title: [Bug] 0.2.1-rc.2 — a permission-presets constructor sweep throw permanently drops the permissions projection

Three findings not covered by #9812 / #10007 / #10040 / #10041:

1. A portable detection criterion. The absolute key count is plugin-composition dependent ([Bug] 运行时重载导致权限选择器消失与工具永久失效：permission-presets 与 auto 预设的依赖死锁（0.2.1-rc.2 仍复现） #10040 reports 28 normal / 27 broken; our machine reports 33 / 32). The portable form is: the only missing projection is permissions. On our machine, 31-key files miss dsh-memoir/activity + mnemonSubagentTokenUsage and 27-key files miss six unrelated projections — both are healthy. Only the single file at 32 keys missing exactly permissions is the bug. Judging by "count went down" produces 20 false positives out of 38.

2. Event-level replay. /permission auto at 10:16:09.156 → first tool failure at 10:16:25.266 (8s later) → 18 consecutive failures across ops_bash / compress / read / glob / working_directory / list_agents / job_list / schedule_list / acp_status / get_goal → turn/end reports {"kind":"completed"} → next turn still dead. No turn/end, dispose, or config-reload event between the switch and the first failure.

3. A user-side workaround. Disabling auto-review in the patch layer removes the precondition of the failure entirely, because pinInitialPermission can then never enter the preset === 'auto' branch that throws. This does not fix the general "mid-turn recompose kills live agents" problem ([Bug]回合运行中改模型/思维强度/权限，会让会话所有工具调用失效（sessionProjections in inactive context） #10007); it only closes the most easily triggered and most damaging entry point.

Additional evidence: in the affected session, self-healing was observed at 12s / 20s / 136s / 294s / 444s / 862s / 1044s gaps without any restart — "restart fixes it" is a misreading; the user restarted 8 times and it recurred every time.

Version check: latest release dsh-v0.2.1-rc.2 (2026-10-17T08:16:33Z, prerelease), last commit 687f282e8 (2026-10-17T07:22:43Z), zero commits since. Verified read-only that the three code paths still exist on 687f282; this is not a validation of any shipped fix.

Request: (1) scope the reject semantics per call site — keep reject-before-publication on session/created, record a pending session instead of throwing from the constructor sweep at :248-250, and re-sweep inside registerAuto(); suggested shape pinInitialPermission(session, { reject }). (2) Withdrawn: this is a one-way hard dependency, not an injection cycle, so decoupling does not break the ring; making it optional only relocates the crash to auto-review's first use. (3) Give a failed row a state of its own before vendor/include returns its veto — the swallowed rejection is the price of that veto, so it cannot be fixed after the promise rejects. (4) End the turn with a named reason when its backing fiber unloads. (5) Guard the unguarded this.autoAdmit() at :435 — auto-review's gate throws by design and the same publication veto applies. (6) Expose a host stderr dump/export switch — the desktop build never flushes the 64KB host stderr buffer on a clean exit, so the diagnostics are lost on exactly the runs where they would help.

[argszero]

What this adds

Thank you for this — the portable criterion (the only missing projection is permissions) and the self-healing gaps (12s / 20s / 136s / 294s / 444s / 862s / 1044s) both correct what the rest of us had, including my own comment in #10007.

This reply adds one source-level distinction that changes two of your five requests, and confirms the other two at the line. Everything below is read off 687f282e.

1. The deadlock is not the throw. It is one throw reached from two call sites with different blast radii.

packages/interaction/permission-presets/src/index.ts:

• :237-244 registers the permissions projection.
• :245-247 ctx.on('session/created', s => this.pinInitialPermission(s))
• :248-250 for (const session of ctx.sessions.list()) this.pinInitialPermission(session)

pinInitialPermission (:428-436) throws at :433 when state.preset === AUTO_PRESET && this.autoAdmit === undefined.

Call site A — session/created. The throw lands inside the publication announcement, and packages/core/session/src/index.ts:45 states what that does: "A synchronous throw vetoes and rolls back with a paired disposal" (see also :1193 for attach). The session is rejected; the service is untouched. This is a deliberate, tested property — tests/permission-presets.spec.ts:300 is named "rejects persisted Auto before publication when its integration is absent".

Call site B — the constructor sweep at :248-250. There is no publication left to revoke. For sessions already in the store, the throw cannot reject anything; its only reachable effect is to fail permission-presets' own fiber, and the permissions projection registered eleven lines earlier goes with it.

The ring then closes with no declared injection cycle. permission-presets injects ['shell', 'approval', 'sessions', 'sessionProjections'] (:201) — it does not depend on auto-review at all. The dependency runs the other way: packages/experimental/auto-review/src/index.ts:127 declares inject = [... 'permissionPresets' ...], a hard requirement. So permissionPresets never publishing ⇒ auto-review stays pending ⇒ registerAuto (:721) never runs ⇒ autoAdmit stays undefined ⇒ the condition that threw never clears.

That is why cold start is spared (list() is empty) and a runtime recompose over a live Auto session is not — and it is the same sentence as your §5 diagram, with the ring located in the failure, not in the wiring.

2. Request (1) should be scoped rather than global; request (2) should be dropped.

Scoped, not global. Making pinInitialPermission never throw would retire the property :300 pins, and that property is worth keeping: auto is not a table entry (:216-218 reserves the name), and specOf (:477) only materialises it while the integration is live. A session published with preset === 'auto' and no gate would record "auto review is enforcing" while nothing enforces it. Rejecting a new session is right.

The defect is that the same exclusivity policy is applied where nothing can be rejected. So the fix is to scope the policy to the caller's ability to reject:

• keep reject-before-publication for a session being created or attached;
• have the constructor sweep (and any later re-sweep) record the session as pending instead of throwing.

The shape that keeps :300 green:

• pinInitialPermission(session, { reject: boolean }) — reject: true from session/created keeps the throw; reject: false from the sweep leaves the session unpinned.
• registerAuto (:307-317), after assigning this.autoAdmit = admit, runs a second sweep and pins whatever was left pending. That is the landing a deferral needs, and it is two lines.
• names (:285) and specOf (:477) already express "Auto exists only while its integration is live", so a pending session has a defined advertisement in the meantime — no new vocabulary required.

Request (2) — make auto-review's dependency optional — I would drop. It is not an injection cycle (§1), so decoupling does not break the ring; and the dependency is real: auto-review reads ctx.permissionPresets at :678 and calls registerAuto / current / set at :689, :721, :729-730. Making it optional moves the crash from permission-presets' constructor to auto-review's first use, and leaves autoAdmit permanently undefined — that is the poison, not the cure. Once (1) is scoped, auto-review activates normally and (2) has nothing left to solve.

A second throw on the same path, which the report does not mention. pinInitialPermission calls this.autoAdmit() at :435 outside any try, and auto-review's gate is a function that throws by design:

// packages/experimental/auto-review/src/index.ts:721-723
permissionPresets.registerAuto(() => {
  if (!accepting) throw new Error('auto-review: integration is closing')
})

accepting is set false at :726, in a different disposer from the one that clears autoAdmit (:312-315). Whichever order those two tear down in, the flag and the registration are not cleared together, so there is an interval in which autoAdmit is still registered and every call into it throws — and from session/created that throw has the same publication veto. The composition is the defect, independent of ordering: gate may throw × pin calls it unguarded × throw vetoes publication. So if you scope the throw, scope this call too — a throwing autoAdmit() at :435 should not be able to reject a session either.

3. Requests (3) and (5): confirmed, with one addition each.

(3) confirmed — vendor/include/src/index.ts:190-201. Worth recording why it is not simply an oversight: the handler deliberately returns without calling next() (the comment reads "Veto the fiber restart (children update in place)") and assigns this.config = config first, so the next refresh() does not re-apply the old overlay. The swallowed rejection is the price of that veto — the handler has already told the host "I handled it", so no path exists by which the failure could be retried. A fix therefore has to give a failed row a state of its own before the veto is returned, not after the promise rejects.

(5) confirmed — apps/desktop/src/host-process.ts:51 MAX_HOST_DIAGNOSTIC_CHARS = 64 * 1024; :204 keeps only the tail ((this.stderr + chunk).slice(-MAX_HOST_DIAGNOSTIC_CHARS)); apps/desktop/src/crash-report.ts:55 records that this tail reaches disk only inside a crash report. The addition: the buffer is not merely capped, it is never flushed — no code path writes it on a clean exit. So the lines you want are lost on exactly the runs where they would be most useful (a working session that never crashes). A second vote for the export switch.

4. What an extension can and cannot do here, so nobody spends a weekend on it

dsh's extension surface is a plugin package (package.json + a dsh.bundle declaration) mounted into a profile's cordis.patch.yml. It composes alongside the core and can shadow a published service instance. It cannot reach a fiber that failed to publish.

• Call site B (the constructor sweep) — core only. The service never publishes, so there is no instance to shadow, and a failed fiber is not retried. No extension can reach it.
• The sibling route does have an extension answer, and it is published. A session opened in a process where the integration is absent is repaired by @argszero/cordis-plugin-permission-restore-guard@0.1.0, which prepends a session/created listener that records a recoverable identity before permission-presets' own listener runs.
• It does not help this report, and I want that explicit so it is not mistaken for a workaround: the guard repairs at publication time, while your replay strands the session after publication — /permission auto appends the identity through apply() (:405), which no session/created listener ever observes. That is precisely why I am arguing for the core fix above instead of pointing at a plugin.

I am happy to turn §2 into a patch against 687f282e if that shape is one you would accept. I have not opened one: the issues channel here is closed, and this is a design call rather than a typo.

[Eviannaive1]

Thanks — this is the most useful reply we could have hoped for, and it corrects us on the two points where we were wrong.

We located the ring in the wiring. We had read permission-presets → auto-review as a declared cycle; it is not one. permission-presets injects only ['shell', 'approval', 'sessions', 'sessionProjections'], and the edge that closes the ring is the absence of a publication, not an injection. That reframing also explains the observation we could never make sense of: restart "fixing" it. Cold start is spared because list() is empty; what actually kills a session is a recompose while a live Auto session is still in the store. That is a far better answer than "restart helps", which is what we had.

The throw is not the defect, the call site is. Reject-before-publication is a property worth keeping and we should not have asked for it to be removed wholesale. Your shape — pinInitialPermission(session, { reject }), true from session/created, false from the sweep, with registerAuto running a second sweep to pick up whatever was left pending — is what we would accept. names() and specOf() already carry "Auto exists only while its integration is live", so pending needs no new vocabulary.

Request (2): withdrawn. Agreed that making auto-review's dependency optional only relocates the crash to its first use while leaving autoAdmit permanently undefined. Poison, not cure.

The unguarded this.autoAdmit() at :435 is a genuine find and we missed it entirely. Same publication veto from session/created, and as you say the composition is the defect regardless of teardown order. It should be scoped together with the first one.

On (3): your point that the swallowed rejection is the price of the veto, and that a fix has to give a failed row a state of its own before the veto is returned rather than after the promise rejects, changes how we would have written that request. Noted, and we will not restate it as "stop swallowing".

On (5): "never flushed, only capped" is worse than what we reported, and we did not have it. Never writing the buffer on a clean exit means the diagnostics are lost on exactly the runs where they would matter.

And thank you for the explicit negative result on extensions — that the constructor sweep is core-only, and that permission-restore-guard repairs at publication time while our replay strands the session afterwards. We would otherwise have gone looking for a plugin workaround and wasted the time.

Yes please: turn §2 into a patch against 687f282e. We can test it on a 0.2.1-rc.2 desktop build with a reproducible live-Auto session — /permission auto, then the first tool call fails about 8s later with no turn/end and no dispose, and the permissions key is missing from the session projection cache. If a patch lands we are happy to report whether the session survives a recompose. We also have the full per-event replay of the failing session and can share it if that is useful for checking the sweep against a real store.