【BUG】开启Auto Review之后重启deepseek harness客户端，权限会自动变为完全访问，且无任何提示。

[MCviseron]

Auto review silently turns into Full access after restarting the DSH desktop client

Environment

• App: @deepseek-ai/dsh-desktop 0.2.0-rc.2 (Windows x64, Electron 44, Node 24)
• Profile: desktop
• Bundles include @deepseek-ai/dsh-experimental-auto-review
• Reproduced with a normal desktop restart (close the client, start it again)

Steps to reproduce

1. Open a session in the desktop client.
2. Select the experimental Auto review preset in the permission picker and confirm the risk prompt.
3. Let at least one tool call run under Auto review.
4. Close the desktop client completely.
5. Start the desktop client again and open the same session.

Actual behavior

The session is now in Full access, with no user prompt and no visible notice event. The previously selected Auto review is gone.

Expected behavior

The persisted Auto selection should either be restored when the Auto review layer is still mounted, or the user should be asked before a silently persisted Full-access migration.

Root cause

@deepseek-ai/dsh-experimental-auto-review registers a disposal effect in packages/experimental/auto-review/src/index.ts:

yield async () => {
  accepting = false
  try {
    for (const session of ctx.sessions.list()) {
      if (permissionPresets.current(session) !== AUTO_PRESET) continue
      permissionPresets.set(session, 'danger-full-access')
    }
  } finally {
    lifecycle.abort(new Error('auto-review integration disposed'))
    await Promise.allSettled([...active])
  }
}

That migration is meant for a live plugin unload (remove/disable Auto review while the host keeps running). But the same disposal runs during the whole host shutdown:

1. The desktop host calls application.shutdown.shutdown(0) from @deepseek-ai/dsh-desktop-host.
2. Cordis unloads the root fiber; the root fiber state becomes UNLOADING before child disposers run.
3. The Auto review plugin disposer still sees its live sessions in ctx.sessions.list().
4. It calls permissionPresets.set(session, 'danger-full-access'), which appends durable permission/preset, sandbox/mode, and approval/policy events to the session log.
5. On the next launch the session restores those persisted knob values, so the user sees Full access with no prompt.

So a client restart performs a persistent permission downgrade that the user never requested.

Suggested upstream fix

Only run the full-access migration when the root fiber is still ACTIVE, i.e. when the Auto review integration is being unloaded at runtime while the host itself keeps running.

--- a/packages/experimental/auto-review/src/index.ts
+++ b/packages/experimental/auto-review/src/index.ts
@@ -727,10 +727,15 @@ export function apply(ctx: Context): void {
     yield async () => {
       accepting = false
       try {
-        for (const session of ctx.sessions.list()) {
-          if (permissionPresets.current(session) !== AUTO_PRESET) continue
-          permissionPresets.set(session, 'danger-full-access')
+        // During a whole-host shutdown the root fiber is no longer ACTIVE.
+        // Migrating then would persist Full access over a stored Auto
+        // selection without any user action; only a live integration
+        // unload needs the migration.
+        if (ctx.root.fiber.state === FiberState.ACTIVE) {
+          for (const session of ctx.sessions.list()) {
+            if (permissionPresets.current(session) !== AUTO_PRESET) continue
+            permissionPresets.set(session, 'danger-full-access')
+          }
         }
       } finally {
         lifecycle.abort(new Error('auto-review integration disposed'))

FiberState.ACTIVE is 2; importing the enum from @deepseek-ai/cordis is preferable if it is exported. A numeric comparison (ctx.root.fiber.state === 2) is equivalent and avoids a new import.

Local workaround

A small host-profile plugin, dsh-auto-review-restart-fix, wraps ctx.permissionPresets.set and drops preset writes whenever ctx.root.fiber.state !== ACTIVE. Mount it before @deepseek-ai/dsh-experimental-auto-review in dsh.profile.bundles so its fiber disposes after the Auto review fiber during shutdown.

Evidence

• @deepseek-ai/dsh-experimental-auto-review/lib/index.js (compiled 0.2.0-rc.2) lines around the auto-review lifecycle effect.
• @deepseek-ai/dsh-permission-presets/lib/index.js PermissionPresetService.set() → apply() → session.append('permission/preset', ...).
• @deepseek-ai/cordis/src/fiber.ts: FiberState and _unload() run disposers while the owning fiber is UNLOADING; the root stays ACTIVE only for runtime plugin unloads.
• @deepseek-ai/dsh-desktop-host/lib/index.js stop() → application.shutdown.shutdown(0).

Impact

• Data loss: a stored Auto selection is overwritten by a silent Full-access migration on every app quit.
• Security: the next session runs with more privilege than the user selected, and the change is not surfaced.
• It affects any desktop/web profile that mounts the experimental Auto review bundle.

[PerryLink]

这是安全相关的一条：权限模式不该"静默升到最宽"

1. 为什么它比普通 bug 重

你写：开启 Auto Review 后重启客户端，权限自动变为完全访问且无任何提示，且在**普通（未提权）**条件下复现。

⇒ 这属于"在用户不知情时放宽权限"：用户以为自己仍在受限模式，实际已是最宽。⇒ 建议在标题/摘要里点明方向：不是"权限没保存"，而是"权限被放宽了"——放宽比丢失严重得多。

2. 最可疑的一类成因（供你验证，不作为结论）

"重启后变成最宽"最常见的原因是：读取该设置时取不到值（缺失/解析失败/键名变更）⇒ 回退到默认，而默认恰好是最宽的模式。⇒ 这正是"fail-open"。

请做一次对照：把该设置在界面里显式设为"受限" ⇒ 重启 ⇒ 看是否仍变宽；再显式设为最宽 ⇒ 重启 ⇒ 看是否保持。

• 只有"受限"会变成"最宽" ⇒ 强烈指向 fail-open；
• 两者都变成最宽 ⇒ 指向"该设置根本没被持久化"。

3. 建议的诉求（两条）

1. 回退必须 fail-safe：设置缺失/无法解析时，应当回退到受限模式（或保持上次已知值），而不是最宽；
2. 变更必须可见：权限模式在任何情况下发生放宽时，都应当明确提示（并在会话里留痕）。

4. 请补三样

1. 该设置在磁盘上的实际值（重启前后各读一次，看它是"没写进去"还是"写进去了但被忽略"）；
2. 是否有日志（你说"无任何提示"——确认日志里也没有）；
3. 版本：你写 0.2.0-rc.2；当前最新是 0.2.1-alpha.1。

5. 一条边界

我没有核对 Auto Review 预设的权限持久化路径（你给的是现象）。⇒ 上面第 2 节的对照能一次分清"没持久化"与"fail-open"，这两个修法不同，请先做它。

[szafranski]

I observed a related case on macOS with DSH Desktop 0.2.1-rc.2 and Cordis 4.0.5, using an unofficial third-party review plugin, call-gate. Before a normal Quit, both checked sessions had Call Gate selected. After reopening Desktop, both had Workspace Write. Our disposer migrates sessions to the profile default during cleanup, so the reset here is our plugin's own behavior, not the permission service changing the preset.

One caveat about the proposed root-state check: Cordis implements root dispose() as restart(). In an isolated test using the installed Cordis implementation, a plugin's disposer saw root UNLOADING for both root.fiber.dispose() and root.fiber.restart(). The root returned to ACTIVE after both operations. The check distinguishes child-only unload from root teardown, but does not establish that the process is shutting down permanently.

Is there a supported way for a plugin to identify permanent application shutdown before its disposer runs, with an ordering guarantee that new tool calls have already been stopped? That would let us preserve the selected preset on shutdown while keeping separate handling for a deliberate plugin disable or unload. Keeping the preset without a running reviewer can otherwise imply protection that is not there, as in the related custom-preset/HMR case in #10040.