Coder/deepseek-harness
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor(mode): modes are collaboration states — drop the access cap; enforcement axes stay independent

Browse Source 
Review follow-up (tianyicui): plan mode and the sandbox are orthogonal
AXES, not just orthogonal state — entering plan must not change what the
sandbox enforces, matching Codex's separation of Plan/Default
collaboration presets from sandbox and approval settings.

ModeDefinition.access, the bash/resolve-mode clamp, and both cap-derived
guards are removed; a ModeDefinition is exactly { section }, and a mode
now carries only its guidance section plus the exit_plan_mode review.
The bash seam's resolveMode + waterfall go with their only listener:
dsh-bash and dsh-tool-bash revert to master byte-for-byte, and the
dsh-mode → dsh-bash dependency edge is gone. A deployment that wants
kernel-enforced read-only planning pairs the mode picker with the
independent sandbox-mode option, in either order.

The RFC archives this as the second removed enforcement shape (after
the interim allowlist) with the same restart trigger — effects
self-declaration; the orthogonality FAQ now answers with the two-axis
rule. The plan example demonstrates the axes side by side, and the
re-recorded fixtures pin the guidance-only section.
This commit is contained in:
kingwl
2026-07-20 13:34:30 +08:00
parent b47b2ba794
commit c0146b9c4a
38 changed files with 1432 additions and 2082 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
docs/config-catalog.md
View File

@@ -508,28 +508,18 @@ export interface ModeConfig {
}
/**
* One mode's deployment-configured policy: the guidance section the model sees
* and an optional cap on the sandbox access shell commands run under. There
* is deliberately no tool allow/deny list — which tools a mode admits is an
* effects question, parked until tool definitions declare their effects.
* One mode's deployment-configured policy: the guidance section the model
* sees. Deliberately nothing else — enforcement knobs (sandbox mode, approval
* policy) are separate axes a mode never touches, and a tool allow/deny list
* is an effects question parked until tool definitions declare their effects.
*/
export interface ModeDefinition {
/** Guidance text rendered as the `mode:policy` prompt section while the mode is in force. */
section: string
/**
* The widest sandbox access shell commands may run under while this mode is
* in force — a per-call CAP on the bash seam's resolved mode (a
* `bash/resolve-mode` clamp), not a switch: the session's own sandbox knob
* keeps its setting and re-emerges intact when the mode ends. Omitted, the
* mode leaves the resolution alone. A mode with `access` set exposes the
* bash tools only while a confining executor is mounted (an unconfinable
* shell cannot honor the cap) and denies sandbox escalation outright.
*/
access?: (typeof SANDBOX_MODES)[number]
}
```
Source: [`packages/mode/mode/src/index.ts:122`](../packages/mode/mode/src/index.ts)
Source: [`packages/mode/mode/src/index.ts:104`](../packages/mode/mode/src/index.ts)
## `@deepseek-ai/dsh-permission`
@@ -980,7 +970,7 @@ export interface Config {
}
```
Source: [`packages/bash/tool-bash/src/index.ts:46`](../packages/bash/tool-bash/src/index.ts)
Source: [`packages/bash/tool-bash/src/index.ts:39`](../packages/bash/tool-bash/src/index.ts)
## `@deepseek-ai/dsh-tool-cordis`