Bug：非扩权（non-widening）的 sandbox_permissions 请求未降级处理，而是直接抛出异常——导致在 workspace-write 和 danger-full-access 会话中，所有工具调用均失败。

[roastfish243895]

Environment

• DSH version: @deepseek-ai/dsh 0.1.1-rc.2 (installed globally via npm, Windows)
• OS: Windows 10/11, dsh web
• Sandbox mode: workspace-write (session default); also reproduced with danger-full-access
• Model: a GPT-family model through the harness adapter

Symptoms

The model attaches sandbox_permissions: "workspace-write" (sometimes with an empty justification) to every tool call — pwsh, bash, fs edits — even though the session's effective mode is already workspace-write. Every call then fails with:

Error: sandbox escalation to "workspace-write" is not strictly wider than this call's current "workspace-write" mode

Making things worse:

• Under danger-full-access every escalation request throws, because WIDER_MODES has no key for it, so WIDER_MODES[effectiveMode] ?? [] is always an empty array → fail-closed. In this mode the error is 100% reproducible and nothing can execute at all.
• Calls with an empty justification additionally throw Error: invalid justification: expected a non-empty sentence.
• Disabling approvals does not help — the throw happens before the approval channel is ever consulted.

Net effect: the agent cannot run commands or write files at all. From the user's perspective this looks like a runtime sandbox fault, not a project issue.

Root cause

In packages/sandbox/sandbox/src/escalation.ts:

1. The tool schemas advertise the escalation surface globally (ESCALATION_TARGETS = ['workspace-write', 'danger-full-access']) whenever a confining executor is mounted — independent of the call's effective mode. The doc comment itself says "schemas are registry-global while the effective mode is per-call truth."
2. The tool description instructs the model to only set sandbox_permissions as a same-turn retry after a denial. In practice models do not follow this discipline reliably and set it speculatively on ordinary calls.
3. approveEscalation then throws on any request that is not strictly wider:

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

So a request that is equal to or narrower than the current mode — i.e. a call that needs no escalation at all — is turned into a hard error instead of being resolved as a no-op. This contradicts the function's own documented stance: "A non-widening request never prompts a human" (it doesn't prompt — it throws at everything).

Suggested fix

Treat a non-widening request as a no-op: grant the call the current effective mode instead of throwing. Genuine strictly-wider escalations keep the existing approval choreography untouched:

const { requestedMode: mode, effectiveMode, justification, subject } = request

// A non-widening request needs no escalation: execute under the current mode.
if (mode === effectiveMode) return effectiveMode
if (!(WIDER_MODES[effectiveMode] ?? []).includes(mode as SandboxMode)) {
  const LADDER: SandboxMode[] = ['read-only', 'workspace-write', 'danger-full-access']
  if (LADDER.includes(mode as SandboxMode) && LADDER.indexOf(mode as SandboxMode) < LADDER.indexOf(effectiveMode)) {
    return effectiveMode
  }
}
// ...original strictly-wider check + approval flow below

This is safe: the granted mode is exactly what the call would have run under had the model simply omitted sandbox_permissions — no privilege is widened, and the approval channel is only engaged for real widenings (verified: read-only → workspace-write and workspace-write → danger-full-access still route through approver.request).

Local workaround (verified)

Patching approveEscalation as above in node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-sandbox/lib/index.js (0.1.1-rc.2) fixes all four branches:

effective mode	requested	before	after
workspace-write	workspace-write	throws	executes under current mode
danger-full-access	workspace-write	throws	executes under current mode
read-only	workspace-write	approval flow	approval flow (unchanged)
workspace-write	danger-full-access	approval flow	approval flow (unchanged)

Checked against v0.1.2-alpha.1 source: escalation.ts is unchanged there, so the issue presumably still applies.

Secondary suggestion: consider filtering the schema enum per-session (only advertise targets strictly wider than the session's effective mode), which would stop models from forming invalid escalation requests in the first place.

Happy to provide more details or test a candidate fix. Thanks for the great project!
（以上内容由GLM-5.3 Flash自动生成）

[argszero]

Interesting — and the root cause is a bit sharper than "approveEscalation throws wrong." I dug into the alpha.1 source and want to add the schema/execution mismatch angle, plus one spec-test wrinkle your suggested fix will hit.

1. The schema advertises the full vocabulary regardless of the session's effective mode — that's what invites the invalid request.

tool-bash/src/index.ts:193 declares:

const escalationModes: readonly SandboxMode[] = defaultMode === undefined ? [] : ESCALATION_TARGETS

So as soon as a composition has a default mode (workspace-write or danger-full-access), it advertises all of ESCALATION_TARGETS (['workspace-write', 'danger-full-access']), and tool-fs/src/sandbox.ts:45 does the identical thing. The enum is registry-global (the doc comment on ESCALATION_TARGETS explicitly says schemas are "registry-global while the effective mode is per-call truth").

The result is exactly the double-bind you describe: a workspace-write session advertises workspace-write as a legal target, the model sets it (it's "already in that mode," so it looks free), and approveEscalation throws on it. The schema tells the model an equal-mode request is valid, then the executor punishes it. That's the mismatch your "secondary suggestion" (filter the enum per-session) is aimed at.

2. Your one-line fix would change tested, deliberate behavior — watch escalation.spec.ts.

packages/sandbox/sandbox/tests/escalation.spec.ts pins the fail-closed ordering:

it('a non-widening request fails closed with its own text and never asks', async () => {
  await expect(approveEscalation(req({ requestedMode: 'read-only' }), spy))
    .rejects.toThrow(/not strictly wider than this call's current "read-only" mode/)
  await expect(approveEscalation(req({ requestedMode: 'workspace-write', effectiveMode: 'danger-full-access' as never }), spy))
    .rejects.toThrow(/not strictly wider/)
  expect(seen).toEqual([])
})

Two things stand out:

• This is not an accident — the whole approveEscalation contract (its JSDoc and this test) treats throwing-on-non-widening as the deliberate fail-closed path. The test's effectiveMode: 'danger-full-access', requestedMode: 'workspace-write' case is narrower-than-current, and the test asserts it rejects — which is correct for a narrowing request (you don't want a request granting less than the call already has).
• But your "equal mode should be a no-op" fix would change only the equal case. The tricky part: distinguishing equal from strictly-narrower requires a ladder, because WIDER_MODES is keyed as "what may I escalate TO" and has no entry for danger-full-access (it's the ceiling). Your LADDER sketch handles this, but it's a new concept the current ladder deliberately omits — danger-full-access has no WIDER_MODES key precisely so nothing is "wider than the ceiling."

3. The cleanest resolution is the per-session enum filter, not the equal-mode special-case.

If the schema only advertises the modes strictly wider than the session's effective mode, then:

• a workspace-write session advertises only ['danger-full-access'] — the model never sees an equal-mode option, so it can't form the invalid request.
• a danger-full-access session advertises [] — no escalation surface at all, which is honest since there's nothing wider.
• read-only (the floor) advertises both, preserving the approval choreography for the genuinely-wider cases.

This removes the invitation to misbehave rather than forgiving the misbehavior after the fact, and it doesn't require weakening the fail-closed contract in approveEscalation (breaking the spec test). It does require escalationModes to be computed from the effective mode (per-call truth) rather than the composition default — but resolveSandboxPolicy already computes standingPolicy.mode per call (tool-bash/src/index.ts:199-230), so the information is available; it currently just isn't threaded into the schema.

Same for the read-only comment: I'd push the fix toward "advertise only what a call can actually escalate to," rather than "turn an invalid request into a silent no-op." The latter works, but it masks the model's mistake instead of preventing it, and it forces the ladder concept into approveEscalation against the existing tested contract.

Verified at v0.1.2-alpha.1 (cd5ef81481): escalation.ts, tool-bash/src/index.ts, tool-fs/src/sandbox.ts, and the spec are all as quoted above.

Happy to help test a candidate fix or run the spec against a --permission-mode matrix. (Note: I'm not able to submit a PR through the upstream channel right now, so I'm keeping this to source analysis on the thread.)

[173787247]

安装 / 环境（「Bug：非扩权（non-widening）的 sandbox_permissions 请求未降级处理，而是直接抛出异常——导致在 workspace-write 和 danger-full-access 会话中，所有工具调用均失败。」）

这类问题优先排除：源/代理、运行时版本、半残缓存。

1. 对齐仓库要求的 Node / Python，不要系统 Python 和 venv 混用。
2. Windows + WSL 或开了代理：Node 24 需要 NODE_USE_ENV_PROXY=1，本机服务加 NO_PROXY=127.0.0.1,localhost。依赖尽量装在 Linux 文件系统，不要放 /mnt/c。
3. npx 卡住就换 pnpm / uv，清掉坏的 node_modules 再装一次。
4. 日志里的 Error: sandbox escalation to "workspace-write" is not strictly wider than this call's current "workspace-write" mode 建议先原样搜本仓 Issues。

补充：系统、node -v/python -V、第一段报错（不用整棵 npm 树）。