dsh-sandbox-arg-guard

1. 安装并启动 DeepSeek Harness：npx @deepseek-ai/dsh web
2. 在终端执行上面的安装命令（CLI 会解析插件并核验来源）
3. 用 dsh plugins list 确认已安装，必要时重启 Harness 生效

插件以当前 dsh 进程的权限运行，安装时可能执行代码。请先通读仓库源码与许可证，确认无破坏性命令与越权访问；本站只做索引，不对第三方插件安全性作担保。

事实信息来自公开插件目录快照（2026-10-01），介绍文案由本站再加工。

以下为插件仓库 README 全文（原始内容，由公开目录抓取整理）。

# dsh-sandbox-arg-guard

**Keeps a redundant sandbox-escalation argument from failing a tool call.**

When an escalating tool (`pwsh`, `bash`, `write`, `edit`) is rejected because the model repeated its
own sandbox level, this plugin re-issues the same call once without that argument — so the call the
model actually intended just runs.

## The failure it prevents

Every escalating tool advertises the full `sandbox_permissions` enum, but DSH only accepts a request
for a level **strictly wider** than the one already in effect. From
`packages/sandbox/sandbox/src/escalation.ts:159-164`:

```ts
// Strict widening is an EXECUTION check against the call's effective mode —
// deliberately not a schema constraint (the enum is the closed target
// vocabulary; the effective mode is per-call truth).
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`)
}
```

The schema therefore cannot tell the model which values are legal *for this call*, and a model that
reflexively passes the argument — a very common habit — picks the level it is already at. The result:

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

Nothing runs. The model gets an error for a call that was perfectly reasonable apart from one
redundant field, and for some models that is a whole turn spent retrying. This is **item 1 of the
community-verified unfixed-issue list** in discussion
[#6520](https://github.com/deepseek-ai/deepseek-harness/discussions/6520) — the most-reported entry
there, with eight directly related discussions and three more in the same family.

## What the plugin does

Registers exactly one `tools/execute` waterfall listener. It calls `next()` exactly once and returns
what it produced. Only when the settled result is that one documented rejection **and** the arguments
actually carried an escalation field does it re-issue the identical call with `sandbox_permissions`
and `justification` removed.

**Why retrying is safe.** `escalation.ts:143-152` states the ordering:

> Resolve a sandbox-escalation request BEFORE anything executes … the tool registry turns the throw into
> the call's isError result, **and nothing has run. A non-widening request never prompts a human.**

Because the rejection precedes any work, re-issuing the same call minus the redundant field cannot
double-apply a side effect. The retry is also **loop-free by construction**: the corrected arguments no
longer contain an escalation field, so they cannot match the rejection pattern again.

**Why this seam and no other.** `tools/pre-execute` and `agent/pre-step` are waterfall hooks that return
a *decision* (`allow` / `ask` / `deny`) — neither can rewrite arguments. `tools/execute` is the one hook
whose return value *is* the execution result, and `ToolRuntime.execute(input)` is public with a
constructible input, so a listener may re-issue a corrected call.

## Verified

BEFORE and AFTER on real session logs, same stub, same tool call — raw output in
[EVIDENCE.md](./EVIDENCE.md):

| | guard absent | guard installed |
|---|---|---|
| `tool/result` | `Error: sandbox escalation to "workspace-write" is not strictly wider …` | `PROBE-EXECUTED` |
| `isError` | `true` | `false` |
| did the command run | no | **yes** |

The session contains exactly one `tool/call` and one `tool/result` in both cases: the retry is not
visible as a second call, and the command did not run twice.

## Install

```bash
dsh plugin --profile web add github:apex-mochen/dsh-sandbox-arg-guard
```

Restart the profile afterwards.

## Configuration

```yaml
- id: dsh-sandbox-arg-guard
  config:
    verbose: false   # log every repair
    enabled: true    # set false to keep it installed but inert
```

| Option | Type | Default | Meaning |
|---|---|---|---|
| `verbose` | boolean | `false` | Log each repair on the diagnostic channel |
| `enabled` | boolean | `true` | Turn the guard off without uninstalling |

## What it deliberately does not do

- **Only that one rejection.** An approval refusal, a genuine permission failure, or a tool's own error
  is passed through untouched — see the `isError` check in `test/smoke.mjs`.
- **Never twice.** A second retry is unreachable; a check asserts it.
- **Fails open.** If the corrected call cannot be issued at all, DSH's original and accurate error is
  what the caller sees.
- **No dependencies.** One implementation file, Node built-ins only. It never spawns, reads, writes, or
  fetches.

## This is a workaround, not a core fix

The real fix belongs in DSH: either make the advertised enum relative to the effective mode, or treat a
non-widening request as a no-op instead of an error. The source comment shows the current shape is
deliberate, so this plugin narrows the gap in **user-visible behaviour** without changing core. DSH does
not accept external pull requests today (`CONTRIBUTING.md`), so a plugin is the reachable seam.

## Compatibility

- DSH `0.1.x` (peer: `@deepseek-ai/cordis ^4.0.1`)
- Node.js 20+
- Registers exactly one waterfall listener (`tools/execute`) and contributes no tools

## License

MIT