danger-full-access mode: tool schema still advertises sandbox_permissions, escalating to "the user rejected ..." when approval policy is forced to never

[Anmulzhao]

TL;DR

When DSH_PERMISSION_MODE=danger-full-access is set:

1. @deepseek-ai/dsh-base/cordis.patch.yml line 191 forces the approval service to policy: "never" (the JS expression (DSH_PERMISSION_MODE ?? 'workspace-write') === 'danger-full-access' ? 'never' : 'ask').
2. ctx.fs.sandboxMode is "danger-full-access" (not undefined), so FsSandboxController in @deepseek-ai/dsh-tool-fs/lib/index.js:1111 still treats the backend as confining and advertises the escalation fields sandbox_permissions and justification on the write / edit (and on bash / pwsh for the shell families).
3. Whenever a model emits one of these tools with sandbox_permissions set, @deepseek-ai/dsh-sandbox/lib/index.js:106 (approveEscalation) hands the request to @deepseek-ai/dsh-user-approval/lib/index.js:175-179, which short-circuits on effectivePolicy === "never" and returns "rejected".
4. The error string returned to the model is "the user rejected escalating this <command|operation> to \"<mode>\"" — verbatim, hard-coded. The model interprets this as a real user refusal and on the next turn retries the same call, looping indefinitely.
5. The model-facing escalation hint (escalationHintMarker in @deepseek-ai/dsh-sandbox/lib/index.js:75-77) tells the model "the approval prompt asks the user", which reinforces the loop.

This is a structural contradiction: the file policy says "no confinement, anything goes", but the tool schema + approval pipeline still pretend the model is in a narrower mode and need to ask the user to widen it — except the user has explicitly forbidden being asked.

Reproduction

1. Set DSH_PERMISSION_MODE=danger-full-access (or set permission: { sandbox: danger-full-access, approval: never }).

2. Start a session and ask the model to perform a write or a shell command.

3. If the model happens to emit sandbox_permissions / justification on the call (the schema still lists them as valid values; the model frequently does so in non-trivial contexts, including when the prior turn emitted a sandbox-denial marker from another session), the call fails with:

   Error: the user rejected escalating this operation to "danger-full-access"
   

4. The model retries with the same sandbox_permissions parameter; the rejection repeats.

The same loop happens for bash / pwsh (Windows) calls.

Why this is a bug, not a UX nit

• The "user" never actually saw an approval prompt — the refusal is synthesized by effectivePolicy === "never". The wording is misleading to both the model and the human reading the transcript.
• Under danger-full-access, the whole point of the mode is "no confinement, no questions asked". Yet the schema still advertises the escalation enum, and the runtime still attempts to escalate, just to fail in a misleading way.
• escalationHintMarker is returned after every sandbox denial — including denials produced under danger-full-access (where the only reason a denial could fire would be a bug in fs-sandbox.checkedTarget or bash-sandbox returning an EPERM that didn't actually require widening). Telling the model to "retry with sandbox_permissions" in policy=never contexts is a self-referential dead end.
• The preset-level mitigation (adding "do not set sandbox_permissions" to the persona prompt) is unreliable: the schema still lists the field, and the tool description for bash / pwsh (in @deepseek-ai/dsh-tool-bash/lib/index.js:129 and @deepseek-ai/dsh-tool-pwsh/lib/index.js:144) actively tells the model to do exactly that on a denial.

Affected versions

Reproducible on the current deepseek-harness distribution as shipped; line numbers above are from node_modules/@deepseek-ai/dsh-base/cordis.patch.yml and @deepseek-ai/dsh-tool-fs, @deepseek-ai/dsh-tool-bash, @deepseek-ai/dsh-tool-pwsh, @deepseek-ai/dsh-sandbox, @deepseek-ai/dsh-user-approval in a fresh install.

Suggested fixes (any one would resolve it)

I think the cleanest fix is at the schema/advertisement boundary, not at the approval outcome:

1. Suppress escalation advertisement when the effective mode is already at the top of the WIDER_MODES ladder. In FsSandboxController (and the bash/pwsh equivalents), do not inject sandbox_permissions / justification into the tool schema when defaultMode === "danger-full-access" — there is nothing wider to escalate to. ESCALATION_TARGETS is intentionally a fixed closed list at @deepseek-ai/dsh-sandbox/lib/index.js:41, but the escalationModes slice in each tool plugin currently still advertises all of them under any confining backend.

2. Make escalationHintMarker policy-aware. When effectivePolicy === "never", return a neutral marker like [sandbox: file access denied under <mode> mode — approval prompts are disabled; no escalation available] instead of instructing the model to retry with sandbox_permissions.

3. Make the never outcome wording honest. Replace "the user rejected escalating this <X> to "<mode>" (in approveEscalation, @deepseek-ai/dsh-sandbox/lib/index.js:106) with something like "approval prompts are disabled in this session; sandbox_permissions cannot widen to "<mode>" — retry without it". This stops the model from thinking a human actively refused.

4. (Optional) Allow dsh-base/cordis.patch.yml to be configured so that policy: never is paired with sandbox: danger-full-access (which already is — see line 203-205), but skip advertising escalation fields under that combination. The shipping default already pairs them; the missing piece is the advertisement-side filter.

Any single one of (1), (2), (3) is enough to break the loop. (1) is the most user-facing; (3) is the lowest-risk.

Workaround we currently use

A small dynamic Cordis plugin that registers a tools/pre-execute listener and denies any write / edit / bash / pwsh call that carries sandbox_permissions or justification. It works, but it's per-session and per-deployment; the structural fix belongs upstream. I can share the plugin source if useful.

Happy to open a PR for any of (1)-(3) — just let me know which direction the maintainers prefer.

References (paths in a fresh install)

• node_modules/@deepseek-ai/dsh-base/cordis.patch.yml lines 169-205 — sandbox / approval wiring, and the never policy hard-coded for danger-full-access.
• node_modules/@deepseek-ai/dsh-fs-sandbox/lib/index.js lines 107-170 — SandboxedFileSystem, checkedTarget, the source of ctx.fs.sandboxMode.
• node_modules/@deepseek-ai/dsh-tool-fs/lib/index.js lines 1102-1188 — FsSandboxController, resolvePolicy, mapError.
• node_modules/@deepseek-ai/dsh-tool-fs/lib/index.js lines 617, 771 — sandbox_permissions injection into write / edit schema when escalationModes.length > 0.
• node_modules/@deepseek-ai/dsh-tool-bash/lib/index.js line 129 — tool description string instructing the model to escalate.
• node_modules/@deepseek-ai/dsh-tool-pwsh/lib/index.js line 144 — same for PowerShell.
• node_modules/@deepseek-ai/dsh-sandbox/lib/index.js lines 41, 75-77, 92-110 — ESCALATION_TARGETS, escalationHintMarker, approveEscalation.
• node_modules/@deepseek-ai/dsh-user-approval/lib/index.js lines 38-39, 155-179 — NEVER_SENTENCE, effectivePolicy, the hard-coded "rejected" short-circuit.

[argszero]

Nice write-up — the structural contradiction is real, and I traced it through the current source to sharpen the diagnosis. One nuance worth flagging (it changes the fix surface slightly).

Three confirmed facts

1. The schema advertises the escalation fields whenever a confining backend is mounted, not "when escalation is possible." In @deepseek-ai/dsh-tool-fs, FsSandboxController computes:

   // packages/fs/tool-fs/src/sandbox.ts:44-45
   const defaultMode = ctx.fs.sandboxMode
   this.escalationModes = defaultMode === undefined ? [] : ESCALATION_TARGETS
   

   ctx.fs.sandboxMode is the capability fact ("is a confining fs backend mounted?"), and ESCALATION_TARGETS is the closed vocabulary ['workspace-write', 'danger-full-access'] (packages/sandbox/sandbox/src/escalation.ts:41). So sandbox_permissions/justification stay on the schema for write/edit (and bash/pwsh — tool-bash/index.ts:192 is the identical pattern) even when the standing mode is already the widest.

2. The strict-widening gate only runs at execution, never at schema time. approveEscalation (escalation.ts:162) checks:

   if (!(WIDER_MODES[effectiveMode] ?? []).includes(mode as SandboxMode)) {
     throw new Error(`sandbox escalation to "${mode}" is not strictly wider ...`)
   }
   

   WIDER_MODES (escalation.ts:28-31) has no danger-full-access key — it's ['workspace-write']: ['danger-full-access'] and ['read-only']: [both] only. So a request to escalate to danger-full-access only passes strict-widening when effectiveMode is workspace-write (or read-only).

3. The never policy short-circuits to rejected before any dispatch. ApprovalService.request → decide (user-approval/index.ts:266):

   if (this.effectivePolicy(session) === 'never') return 'rejected'
   

   which approveEscalation maps to the verbatim the user rejected escalating this ${subject} to "${mode}" (escalation.ts:184).

The nuance your numbers imply

The quoted error the user rejected escalating this operation to "danger-full-access" is only reachable when the per-call effectiveMode is narrower than danger-full-access (i.e. workspace-write or read-only). If the effective mode were genuinely danger-full-access, fact #2 fires first — strict-widening throws not strictly wider than this call's current "danger-full-access" mode — and approval is never reached.

So there are really two distinct failure shapes depending on what SandboxPolicyService.resolve returns for that session:

effectiveMode	model asks danger-full-access	result
workspace-write	✓	passes strict-widening → never policy → the user rejected ... (your repro)
danger-full-access	✓	strict-widening throws first — not strictly wider ... (no human involved at all)

Both are the same root bug (schema advertises a lever the composition can't honor), but they surface differently and the model-facing text is misleading in both.

Why this is a real model-facing contradiction

NEVER_SENTENCE (user-approval/index.ts:66) already instructs the model deterministically:

"Approval prompts are disabled in this session: actions that require approval are rejected automatically — do not request sandbox escalation (do not set sandbox_permissions)."

Yet the schema still lists sandbox_permissions as a valid enum value, and the never-policy rejection is worded as "the user rejected" — which reads like a real human refusal, exactly the thing that makes the model retry the same call on the next turn. The model-facing vocabulary violates the deterministic-never promise with an anthropomorphic refusal string.

Fix directions (for anyone picking this up)

• Schema: advertise the escalation fields only for modes that are actually strictly-wider-eligible — i.e. gate on whether WIDER_MODES[effectiveMode] is non-empty, not on sandboxMode !== undefined. The ESCALATION_TARGETS-when-undefined shape in sandbox.ts:45 conflates "a confining backend is mounted" with "this call can widen."
• Error string: distinguish a deterministic-policy rejection from a real human one. Under never, return something like "sandbox escalation is disabled in this session (approval policy: never)" rather than the user rejected .... That kills the retry loop on its own.

The WIDER_MODES / ESCALATION_TARGETS split (escalation.ts:28-41) already documents why schemas are registry-global while widening is per-call — the bug is that neither the schema nor the error text consults the per-call effective mode at the point where the model sees them.

— argszero