Files
deepseek-harness/packages/ui/permission
Tianyi Cui cfceb8452b subagent: seed inherited policy events at creation
The parent implementation introduced sandboxMode and approvalPolicy as generic SessionHeader fields, then propagated those fields through both persistence backends, session-query indexes, collision checks, policy-specific seed-boundary folds, catalogs, and a broad test matrix. That storage plane is unnecessary: Session already accepts a validated constructor seed, and persistence captures that seed when the session is announced before committing its first batch.

Capture each parent override synchronously at delegation, append source-tagged sandbox/mode and approval/policy records after the optional fork prefix, and create the child with that combined seed. Keeping header.seedLength at the original fork-prefix length preserves lineage while ordinary last-event-wins folds make the inherited records outrank stale parent history and remain subordinate to later child switches. Unswitched parents still stamp nothing, so children continue to follow deployment defaults.

Remove the generic header fields and every persistence/query/schema branch built around them. Collapse the inheritance suite from ten leaking scenarios to four owned-context cases covering real filesystem confinement, stale fork precedence, delegation-time capture, and the no-override path. The assembled headless snapshot now asserts the persisted inheritance event directly.

This keeps the security behavior while restoring policy ownership to the existing event log and deleting the speculative durability machinery that the original tests did not exercise.
2026-07-28 21:31:17 +08:00
..

@deepseek-ai/dsh-permission

English | 中文

User-facing permission presets through ctx.permission (PermissionService). Each configured name bundles sandbox/mode with approval/policy; the defaults are workspace-write (workspace-write + ask) and danger-full-access (danger-full-access + never). UI adapters may expose the table as one selector, while sandbox execution and approval continue to consume their own knobs.

set(session, name) records a changed selection in a log-only permission/preset event, then calls each knob's setter only when its effective value changes. The selection event precedes the knob events and preserves user intent when presets share a bundle; a net-zero selection appends nothing. current(events) prefers a still-matching recorded selection, then the first matching table entry, and otherwise returns custom. Clients may display custom as the current value, but cannot select it.

The service requires a confining ctx.bash executor and ctx.approval. A table entry named custom throws at load; composition defaults outside the table instead make a zero-event session derive custom. See the sandbox switching design.

Model Experience

Indirectly, through dsh-user-approval and dsh-tool-bash, which render the approval-policy prompt, switch notice, and sandboxed tool outcomes selected by this service's knob events; permission/preset itself is log-only.

KV Cache effect

No direct invalidation; the named consumer owns any request-prefix changes.

Known Limitations and Deferred Work

  • No shipped composition currently mounts the service — the ACP bridge was its only selector before ACP became automation-only; the preset table is kept for the interactive front door that next exposes a runtime policy switch.
  • Only two mechanism knobs are bundled — presets select sandbox mode and approval policy; an agent/profile choice is not part of PresetSpec yet.
  • custom is derived-only — callers can switch away from an unmatched knob combination but cannot target or persist a named custom preset through this service.
  • The preset table is process-level — configuration is fixed for the plugin lifetime; changing available presets requires reloading the plugin.