[Bug] A restored session that still carries the durable "auto" preset makes permission-presets throw in its constructor, leaving auto-review pending — "2 entries did not activate"

[tianguoyan]

Environment

• DSH desktop 0.2.0-rc.2, Windows x64 (Electron; profile desktop)
• @deepseek-ai/dsh-permission-presets 0.2.0-rc.2
• @deepseek-ai/dsh-experimental-auto-review 0.2.0-rc.2
• Update feed win-x64/nightly still reports 0.2.0-rc.2 (releaseDate 2026-09-29), so there is no newer build to retest on.

Summary

If any session that is already loaded when the permission service is constructed still has the durable preset identity auto (i.e. /permission auto was used in it at some earlier point), PermissionPresetService throws from its own constructor. The permission entry therefore never activates, and auto-review — which needs the permissionPresets service — stays pending forever.

Observed boot warning (desktop):

dsh: warning: 2 entries did not activate
permission (@deepseek-ai/dsh-permission-presets): Error: permission: cannot restore
preset "auto" without its active integration at PermissionPresetService.pinInitialPermission
at new PermissionPresetService ... at Fiber.execute ... at <profile>/#permission
<profile>/#include auto-review (@deepseek-ai/dsh-experimental-auto-review);
pending (waiting for service: permissionPresets)

Root cause

Three pieces that cannot be ordered to satisfy each other:

1. packages/interaction/permission-presets/src/index.ts — pinInitialPermission() treats a persisted auto identity as fatal when the integration is not registered yet:

if (preset === "auto") {
  if (this.autoAdmit === void 0) throw new Error('permission: cannot restore preset "auto" without its active integration')
  this.autoAdmit()
}

2. The same file's constructor pins every already-loaded session during construction:

for (const session of ctx.sessions.list()) this.pinInitialPermission(session)

3. packages/experimental/auto-review/src/index.ts can only register that integration after the service exists (static inject includes permissionPresets, and it calls permissionPresets.registerAuto(...)).

So at construction time autoAdmit is always undefined. Any boot whose restored session carries auto fails deterministically, and once the entry fails there is no later point at which the integration could arrive. The failure is not recoverable inside that instance either: because permissionPresets never mounted, /permission is unavailable, so the user cannot switch that session back from inside the app.

Steps to reproduce

1. Boot normally (auto-review mounted and healthy). In session A, run /permission auto — this appends a durable permission/preset { preset: "auto" }.
2. Make sure session A is not among the loaded sessions when the app exits, or kill the app without a clean shutdown. (On a clean shutdown auto-review's disposal effect rewrites loaded sessions that are on auto back to danger-full-access, which masks the bug — see the related discussion below. A session that is not loaded at exit keeps auto.)
3. Start the app again with session A being the session that gets restored.
4. The warning above appears; auto is unusable in that instance and /permission is dead.

Evidence from one machine (desktop profile, DSH 0.2.0-rc.2)

Session A's log (session.v4.jsonl, timestamps UTC):

seq	time	event
4	2026-10-14 12:15:37	permission/preset {"preset":"auto"} (from /permission auto)
5	2026-10-14 12:15:37	sandbox/mode {"mode":"danger-full-access"}
1490	2026-10-15 10:53:35	session/end-seed — this session was the one restored by the failing boot
1491	2026-10-15 11:18:38	permission/preset {"preset":"danger-full-access"} (written by the disposal migration of a later clean exit, no command/run event)

The identity survived ~23 h across several app starts, because the disposal migration only rewrites sessions that happen to be loaded at that moment. A later boot that restored a session whose identity was workspace-write was clean, and /permission auto / /permission workspace-write / /permission auto worked normally in it — which confirms the trigger is the restored session's stored identity, not the profile configuration.

Identity audit (folded from permission/preset events in every session log on that machine, 69 sessions): auto = 29, workspace-write = 16, danger-full-access = 9, none = 15. All 29 auto sessions are latent triggers for this bug.

Impact

• In an affected instance the whole auto-review integration is unavailable (the permission layer it augments never mounts), and the permission preset service is down, so the user cannot recover in-app — only a restart with a different session as the restored one helps.
• The sandbox mode and approval policy knobs themselves keep working; no session data is lost; the warning is non-fatal for the rest of the app.

Suggested fix

Make the restore lazy instead of fatal. Options, in my order of preference:

1. Don't throw for sessions that already existed at construction: leave the auto identity in place and let registerAuto() run the restore/admission check for exactly those sessions once the integration arrives (it already has to pass autoAdmit() before publication, so the check is not lost — it is only deferred).
2. Keep the throw, but only for sessions created after the service is up (there the integration can legitimately be expected).
3. At minimum, make it non-fatal and visible: log the failure, keep the identity, and let the integration recover it on registration, instead of knocking out both entries.

Related

• 【BUG】开启Auto Review之后重启deepseek harness客户端，权限会自动变为完全访问，且无任何提示。 #8578 — "Auto review silently turns into Full access after restarting the DSH desktop client". That report covers the disposal migration running during a whole-host shutdown. This report is the complementary half: the migration only reaches loaded sessions, so any other session keeps the auto identity and poisons the next boot that restores it. Fixing 【BUG】开启Auto Review之后重启deepseek harness客户端，权限会自动变为完全访问，且无任何提示。 #8578 without deferring the restore will still leave this failure.
• /permission 切换失败在界面上不可见，且被拒的切换会留下名不副实的 preset 记录 #8770 — silent /permission switch failures. Related symptom family (preset records that do not match reality), but a different defect.

Workaround (no code change)

Before quitting the app, switch the session you are leaving active back to a core preset (/permission workspace-write or /permission danger-full-access). auto can still be used temporarily; just don't leave a session on it.

[argszero]

Your trace is right on all three pieces. What is worth making explicit is that this is not an ordering race a lucky boot can win — it is a deadlock with exactly one outcome, and it is provable from the declarations alone.

Where the three pieces are, on master (the TS sources behind the bundle you read):

• packages/interaction/permission-presets/src/index.ts:428-436 — pinInitialPermission(); the throw is :432-433.
• packages/interaction/permission-presets/src/index.ts:248-250 — the loop over ctx.sessions.list(), and it sits inside constructor(ctx, config) (opened at :207), next to the session/created listener at :245-247.
• packages/interaction/permission-presets/src/index.ts:307-316 — registerAuto(), the only writer of autoAdmit.
• packages/experimental/auto-review/src/index.ts:721 — the only caller, and auto-review's dependency list (:127) contains permissionPresets.

So registerAuto cannot run before the service exists, and what calls pinInitialPermission during construction is the service's own constructor. autoAdmit === undefined therefore holds for the entire constructor, always. Any boot whose loaded set contains one session whose folded permissions state has preset === 'auto' fails on the first construction of that entry — deterministically, not conditionally.

The blast radius is the whole entry, in one direction, with no way back up. The constructor throws, so permission never activates; names (:285) offers auto only while autoAdmit !== undefined, so Auto can never be selected again; the /permission command handler (:255-276) is registered from the same constructor, so it never exists; and auto-review stays pending on permissionPresets. That is why the app has no in-product path: the only writer of a session's preset is inside the object that failed to construct. Note the asymmetry your report exposes: selecting Auto succeeds without the integration (apply() runs this.autoAdmit?.() at :405 — an optional call), and restoring it requires the integration. One side tolerates the absence; the other treats the same absence as fatal.

The same line has a second blast radius, which you may not have hit yet. The listener at :245-247 calls the same pinInitialPermission, and a synchronous throw there does not merely warn — packages/core/session/src/index.ts:45-48 (the session/created contract): "A synchronous throw vetoes and rolls back with a paired disposal." On that path the session is rolled back, the client is told api-session/removed, and the row leaves the sidebar while its log stays complete and unopenable — every attempt to open it takes the same path to the same throw. Your build shows the constructor variant (2 entries did not activate); the tell for the other one is a session row that disappears when opened, rather than a boot warning naming entries. Same defect, two symptoms, and the second one is unrecoverable from inside the product.

A partial remedy already exists, with a boundary worth knowing about. We published @argszero/cordis-plugin-permission-restore-guard@0.1.0 (npm, repo) for the other variant: it prepends a session/created listener that records a restorable identity before the refusal can fire, so the veto never lands and the session keeps every event it ever had (it writes no knob, so no session's sandbox mode or approval policy changes). It also ships a tool that reports and repairs sessions already in that state. It cannot cover your case, because no session/created event fires for sessions that are already loaded when the service constructs — for the constructor path the reachable half is the repair tool: rewriting the recorded identity means the next boot's loop finds a configured preset and the entry constructs. That is a workaround for a user in the state, not a fix for the state.

What the fix looks like from here. The write side already tolerates a missing integration, so the read side should not be fatal about the same absence. Two shapes, either of which breaks the cycle:

1. Defer. Do not restore auto at construction. Keep the durable identity and resolve it at the first point where the integration is knowable, when it can be reported or refused where a user can act on it.
2. Degrade. Treat an unrestorable auto as a preserved-but-inert identity and record the effective preset the way the rest of the method already does for partially initialized state (:446-455) — boot succeeds, the session stays listed, and the reason is visible.

Either way the invariant worth writing down is narrow: the constructor may only act on facts knowable at construction time; a fact that depends on a later-registered integration must be deferred to first use. The auto identity is the only such fact in this file today.

One more data point that would help if you can still reproduce: does the boot warning's entry count include auto-review as one of the two, or is there a third entry that fails for its own reason? That distinguishes "permission + its dependent" from a wider composition failure in the same profile.

[little3tar]

Corroboration with a third trigger shape — and one consequence for the fix proposals.

The same throw is reachable at runtime, not only from a boot that restores a session carrying auto. Any event that reconstructs the permission-presets fiber while loaded sessions still carry auto fails deterministically: the constructor's for (const session of ctx.sessions.list()) loop runs again, autoAdmit is undefined again (its only writer, auto-review, is itself waiting on the service being reconstructed), and the throw at :432-433 lands exactly as in your boot case. A clean boot only survives because no sessions are loaded yet when the service first constructs — a runtime reconstruction has no such cover.

One very ordinary source of such a reconstruction is a third-party plugin applying a runtime config overlay to the official executor row: entry.fiber.update() on an ACTIVE @deepseek-ai/dsh-pwsh-sandbox row is a full dispose/reload (cordis fiber.update → restart()), which swaps the host's shell service provider and rebuilds every inject('shell') consumer — permission-presets among them.

Observed on DSH 0.2.0-rc.2 / Windows with one session pinned to auto: hot-installing or hot-toggling such a plugin reproduced exactly the error you quoted, plus pending (waiting for service: permissionPresets), and every later hot plugin operation re-triggered it until a restart. The plugin side is reported at T-Auto/dsh-ops#29, #104, #129; its overlay no longer restarts the row (T-Auto/dsh-ops#154 — it now commits into the live pwshPath volatile reference instead, which the executor re-reads before every command).

For the fix: your defer option covers this shape too — provided the deferred set is resolved when registerAuto() arrives; that resolution is what re-pins the stored auto sessions. A degrade-only variant would leave this runtime case alive: the session keeps an inert auto identity, and the next reconstruction re-enters the same path.

One extra hardening worth considering while you are in there: auto-review's tools/pre-execute hook (registered prepend) calls permissionPresets.current() unconditionally — before even checking whether the session is on auto — so this single failed service takes down every tool of the instance, including tools with no relation to permissions (trace in T-Auto/dsh-ops#129).

[potato1314520666]

EN summary: Same bug on my machine (0.2.1-rc.2, Windows). Session logs say it's worse than
"switching models freezes things": any profile write triggers it — 509 occurrences across
95/157 sessions in my logs, one event killed 57 sessions at once.

While patching it I found one throw site that I don't think has been mentioned here yet: if the
global auto-review toggle is on, defaultPreset becomes "auto" and the constructor fails at
its very first validation (lib/index.js :181/:184), before it ever reaches
pinInitialPermission. autoAdmit is only registered by the auto-review plugin after
construction, so guarding just the pin site won't save a machine with global auto enabled.

I put the byte-level patch I run on my machine here: https://github.com/potato1314520666/sessionprojections-patch (covers both sites, with backup
and rollback). It's a workaround, not a fix — the real problem is that the host rebuilds the
whole plugin graph on every config write, with no equality gate before entry.update(). That
part is up to the maintainers.

Big thanks to @tianguoyan, @argszero and @little3tar — the map in this thread was right, I
just filled in one blank spot.

---

中文：

我这台 0.2.1-rc.2/Windows 也中了同一个 bug。翻了全部会话日志之后发现问题比"切模型卡死"更宽：
任何 profile 写盘都会触发（切模型、切权限、热改插件、dsh-ops 更新配置都算）。我的日志里
同一个错误出现了 509 次，波及 95/157 个会话，10-19 有一次一口气打挂 57 个会话。

打补丁的过程中发现一个本帖还没提到的炸点：如果全局自动审查是开着的，defaultPreset 就是
"auto"，构造器会在最开头的校验（:181/:184）直接抛——走不到 pinInitialPermission 那个
大家关注的 throw。因为 autoAdmit 是 auto-review 在构造之后才注册的。所以只保护 pin 点的
方案，救不了开着全局自动审查的机器。

我自己机器上跑的字节级补丁放在这：**https://github.com/potato1314520666/sessionprojections-patch**。两处抛点都盖住了，带备份和回滚，装完重启生效。
说清楚：这是止血，不是根治。真正的病根是宿主每次写配置都无条件重建整个插件图
（config_editor.js:75，而且死 fiber 上的 isChanged 恒判"变了"，每次写都升级成全图协调）。
entry.update() 前面加个等值门应该就能解决大半，这个得官方来改。

各方案的分工大概是：

	解决什么
@argszero 的 restore-guard	会话行消失那个变体
dsh-ops #154	dsh-ops 自己引发的重建
我的补丁	重建时 auto 会话卡死 + 上面那个更早的炸点

互相不冲突。局限也写在我仓库 README 里了：版本钉死 rc.2、auto 会话遇重建会被降级、
构造期降级的阳性事件我还没抓到过一次（触发面比较挑时机）。

感谢 @tianguoyan 的启动形态定理、@argszero 的死锁确认、@little3tar 的重建形态分析，
这个帖子的地图基本是全的，我就是补了一格。