# A persisted auto permission preset makes a session permanently unopenable when the Auto integration is absent ##

[wqing120-svg]

Summary

A session whose recorded permission preset is auto cannot be opened at all once the
Auto review integration is not live. The host fails to resume the session, disposes it, and
the client marks it removed — the input bar shows "Session unavailable" and the session
disappears from the sidebar. The session data on disk is intact; there is no in-product
way to recover it.

The failure is asymmetric and that asymmetry is the bug:

• Switching a session to auto succeeds silently even when no integration is registered
  (apply() calls the optional this.autoAdmit?.()).
• Restoring the same session hard-fails when the integration is absent
  (pinInitialPermission() throws).

So a preset that can be written at any time can become unrestorable after a restart, with
no warning and no user-facing remedy.

Affected

• @deepseek-ai/dsh-permission-presets@0.1.7-rc.2
• @deepseek-ai/dsh-api-session-controller (emits api-session/removed)
• @deepseek-ai/dsh-client-ui-conversation (renders the disabled composer)
• Reproduced on DSH Desktop 0.2.0-rc.2, Windows 11 x64, bundled runtime 0.2.0-rc.2

Steps to reproduce

1. On a host without the Auto review integration installed (i.e. the default install —
   @deepseek-ai/dsh-experimental-auto-review is not shipped; the shipped preset table has
   only workspace-write and danger-full-access), write a session's preset as auto.
   Any third-party preset provider that names its preset auto does this — that was the
   trigger here (dsh-auto-approve@0.6.2, whose preset id was later renamed to
   sandboxed-auto precisely because auto became reserved).
   On dsh ≥ 0.1.7 a configured preset cannot be named auto, but a recorded auto
   selection is still produced by any integration that registers one.
2. Restart DSH so the integration is no longer live.
3. Open the session from the sidebar.

Expected behavior

Any one of:

• the switch to auto is rejected while no integration is registered (fail at write time, not read time);
• the session opens with the preset downgraded/flagged, instead of being refused;
• failing both, the session stays visible with an actionable error and an in-product way to clear the preset.

Actual behavior

• resume failed for session "<id>": Error: permission: cannot restore preset "auto" without its active integration
• the session is disposed → client receives api-session/removed → snapshot removed: true
• composer renders disabled with placeholder 会话不可用 / "Session unavailable";
  sidebar filters the session out entirely
• every subsequent open fails identically; a page reload does not help

Root cause (source)

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

// hard-fails on restore
private pinInitialPermission(session: Session): void {
  ...
  if (preset === AUTO_PRESET) {
    if (this.autoAdmit === undefined) {
      throw new Error('permission: cannot restore preset "auto" without its active integration')
    }
    this.autoAdmit()
  }
  ...
}

// but writing the same value never checks
private apply(session: Session, name: string, setApproval: (policy: ApprovalPolicy) => void): void {
  const spec = this.resolve(name)
  if (name === AUTO_PRESET) this.autoAdmit?.()      // <- optional; silent when absent
  ...
  session.append('permission/preset', { preset: name })
  ...
}

publishAgentAvailability / ctx.on('session/disposed', …) in
packages/api/session-controller then relay the removal:

ctx.on('session/disposed', (session) => {
  ctx.emit('api-session/removed', session.id)
})

and the client turns that into a permanently locked composer
(dsh-client-ui-conversation: const disabled = removed || inert || !live || blocked !== undefined).

Impact observed: in one install, 3 of the sessions the user actually works in were
affected (25 sessions total across the store recorded auto; the rest were archived or
delegated-child sessions that are not listed anyway).

Suggested fix

Pick whichever fits the design intent, but the write side should not be able to create a
state the read side refuses:

1. Validate on write — apply() should throw (or downgrade + warn) when
   name === AUTO_PRESET && this.autoAdmit === undefined, mirroring pinInitialPermission().
2. Degrade on read — pinInitialPermission() should not throw for a stale auto
   identity; treat it as custom/the composition default, keep the session openable, and
   surface a notice. (The permission/preset event is log-only user intent, so the durable
   identity is preserved either way.)
3. Make it recoverable in-product — even with 1+2, an already-poisoned store needs a way
   out that is not "edit the session log by hand".

Workaround used

Append a superseding permission/preset (+ sandbox/mode) event to the session log,
overwriting the auto selection. This works because the file is a multi-frame zstd container
of JSONL events and the last selection wins — but it requires stopping DSH and hand-editing
the .zstd, which is not something users should have to do.

{"type":"permission/preset","seq":<next>,"time":<ms>,"data":{"preset":"workspace-write"}}
{"type":"sandbox/mode","seq":<next+1>,"time":<ms>,"data":{"mode":"workspace-write"}}

Related

• The community plugin dsh-auto-approve documents this exact failure in its README
  ("a session whose recorded preset is auto fails to open on dsh 0.1.7+ while the official
  Auto review is off, with cannot restore preset "auto" without its active integration.
  Its data is not lost; it just cannot be opened for now.") — the failure mode is known to
  third parties but the docs do not warn about it: the permission-presets subsystem page
  only says a stored auto session "requires the live Auto registration before Agent
  publication", without saying the session becomes unopenable.
• Adjacent Auto-review reports: auto-review fails with HTTP 400 on providers that require a session header (e.g. OpenCode Go) #8726 (MissingSessionID on providers needing a session
  header), Bug: OpenCode Go requests fail with MissingSessionID #6467, Make web search follow the session's LLM route (and support gateway routing headers) #8512 — this report is a different failure (session lifecycle, not reviewer transport).

[argszero]

Confirming this from the source at origin/master, and adding the four facts that decide how it can be fixed — one of them changes where the fix has to live.

Both ends, located

Write end — packages/interaction/permission-presets/src/index.ts, apply() (line 403):

private apply(session, name, setApproval): void {
  const spec = this.resolve(name)
  if (name === AUTO_PRESET) this.autoAdmit?.()          // optional call: absence is not an error
  ...
  if (current !== name) session.append('permission/preset', { preset: name })

Restore end — pinInitialPermission() (line 428):

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

So the asymmetry is exactly as you describe, and it is one line of optional call against one line of throw.

Why the failure is so total. The restore path is not called by the opener — it runs from this service's own session/created listener (line 245) and from the constructor sweep over ctx.sessions.list(). dsh-session's announce() deliberately lets a synchronous session/created throw veto publication ("a throwing session/created listener rolls the attach back", packages/core/session/src/index.ts:985). That is the mechanism behind everything you observe: the throw is not a warning attached to a live session, it is the publication transaction unwinding — hence resume failed, api-session/removed, the disabled composer and the sidebar dropping the row, with the log on disk untouched. The severity is a consequence of where the check sits, not of the check itself.

The write path is not the one a fix would naturally guard

The public method is set(session, name) (line 396) and its docstring invites wrapping. But the shipped web popup does not go through it: it submits /permission <preset>, and that command's handler (line 272) calls the private apply() directly. set() is what dsh-webhook uses (packages/webhook/webhook/src/session.ts:151) and what auto-review uses to downgrade (packages/experimental/auto-review/src/index.ts:732). A guard added to set() alone would leave the desktop's own UI able to write the poison. If the write end is where this is fixed, it is apply() (or a rule on the recorded permission/preset event) that has to carry it.

A public liveness probe already exists

get names() (line 285) is:

return [...Object.keys(this.presets), ...(this.autoAdmit === undefined ? [] : [AUTO_PRESET])]

'auto' appears in the advertised catalog iff an integration is registered. So "is this session's auto restorable in this process?" is answerable without touching a private field — permissionPresets.names.includes('auto') — which is the predicate your "rejected while no integration is registered" option needs.

The third expected behaviour is reachable today, without rewriting history

You listed "the session opens with the preset downgraded/flagged" as an alternative to failing at write time, and that one does not need the write end changed. The durable record is a single permission/preset session event, and the permissions projection takes the last one (applyPermissionEvent). Appending a later permission/preset therefore is the downgrade — no log rewriting, no header surgery.

The ordering supports it, too: announce() resolves its listener snapshot up front and calls listeners in registration order, and ctx.on(..., { prepend: true }) unshifts. A listener prepended to session/created runs before this service's, and appending from inside a session/created listener is exactly what pinInitialPermission already does on the fresh-session path — so by the time the service reads stateOf(session, 'permissions'), the folded preset is no longer auto and its own guard never fires. (One thing that does not work: appending from a session/event observer. append() rejects reentry while another append is publishing, so an "correct the log right after it is written" hook has to wait for a different edge.)

Guarding the write and repairing the restore are both worth having; they are not the same fix, and the second one is the one that rescues the sessions that are already in this state.

We are prototyping the restore-side half as an out-of-tree plugin (public probe above, no core change) and will follow up here with the result either way — including if it turns out not to carry its weight.

[argszero]

Following up on this thread with the plugin I said I would report back on, since the fix shape here turns out to be reachable from outside the core.

@argszero/cordis-plugin-permission-restore-guard@0.1.0 — https://www.npmjs.com/package/@argszero/cordis-plugin-permission-restore-guard (source)

npm install @argszero/cordis-plugin-permission-restore-guard

# in a dsh profile's cordis config
- id: permission-restore-guard
  name: '@argszero/cordis-plugin-permission-restore-guard'

It registers a listener on session/created with { prepend: true }, so it runs inside the same publication boundary as the permission service's own listener and before the refusal. That listener appends one permission/preset event naming an identity the service can restore — the operator's configured preset when it resolves, otherwise a configured preset whose sandbox mode and approval policy already equal the session's, otherwise custom (the name derive() itself reports for those knobs, so the stored identity and the identity the picker computes agree). It writes no knob: sandbox mode and approval policy are whatever they already were, and the log keeps every event, including the Auto selection that could not be restored. auto is never recorded, even where the knobs match the Auto bundle — that would seal the session again on the next open.

Ordering is the load-bearing part, and the suite measures it rather than asserting it: a listener registered after the service cannot prevent the throw, because announce() takes its listener snapshot up front and the first throw rolls the publication back. Appending from a session/created listener is what the service already does when it pins a fresh session, so this is not a new kind of write — the negative result I hit along the way is that the same append from a session/event observer is refused (append cannot reenter while another append is being published), so the correction has to happen on the created edge.

A permission_restore tool covers the half a listener cannot reach: a session that is already stranded on disk cannot be opened, so nothing runs for it. The tool sweeps the live sessions in the process, reports preset auto with no live integration, and records the replacement identity when called with confirm: true. It is mounted read-only by default (mode: "report" says what it would record and writes nothing); any failure inside the listener ends as a warning rather than a lost session, since a guard that can fail a publication is worse than no guard.

Evidence, so the claim is checkable rather than interesting: 58 tests against the real dsh-session store, the real projection registry and the real permission service (ctx.shell/ctx.approval are the only stand-ins); a defect injector that mutates one distinction at a time and requires the suite to notice; and the peer range measured rather than asserted — 0.1.7-alpha.1, 0.1.7-rc.2 and 0.2.0-rc.2, each with the whole line pinned from that line's own dsh-agent manifest. Two of those lines record different identities because the Auto bundle itself differs between them (danger-full-access/never on one, danger-full-access/ask on another), which is why the suite derives the expected name from the knobs instead of pinning one.

Two limits worth stating plainly. It does not re-register the Auto integration and does not restore what Auto did — what a repaired session loses is the Auto admission hook, which is exactly the thing that cannot come back without its integration. And the underlying asymmetry in this report is untouched: the write side still silently succeeds through an optional call while the restore side throws, in a listener whose throw is fatal to the publication. The plugin removes the consequence for sessions it can reach; it does not remove the asymmetry.