Bundle
@deepseek-ai/dsh-escalation-tolerance
Tolerate redundant sandbox_permissions requests: a tool call asking to escalate to a mode that is not strictly wider than the session's standing mode runs as-is at the standing mode instead of failing with "not strictly wider". Genuine escalations still route through the approval flow.
- Source
- ericleoo
- License
- MIT
- Updated
- Updated 14 days ago
Readme
# @deepseek-ai/dsh-escalation-tolerance
Tolerate redundant `sandbox_permissions` requests – a Cordis plugin that turns hard failures into harmless no‑ops when a tool asks for a permission mode that is already active.
## Problem
Some GPT‑family models (e.g., `gpt-5.6-luna`, `azure/gpt-5.4-mini`) **speculatively** send `sandbox_permissions` on ordinary tool calls, even when the session already runs at that permission level. The shared escalation validator (`@deepseek-ai/dsh-sandbox`) expects any escalation request to be **strictly wider** than the call’s effective mode; otherwise it fails with:
```
sandbox escalation to "<mode>" is not strictly wider than this call's current "<mode>" mode
```
This means a trivial `pwd` can crash the tool if the model adds a redundant `sandbox_permissions` field.
## Solution
This plugin hooks into the `tools/execute` waterfall and inspects the requested `sandbox_permissions`. If the requested mode is **not strictly wider** than the session's standing mode, it strips both `sandbox_permissions` and `justification` from the arguments. The tool then executes at the standing mode – exactly what would have happened had the model not sent the redundant request.
**Genuine escalations** (modes that are strictly wider) are left untouched and still go through the normal approval flow.
> **Security note:** No security boundary is changed. Stripping the redundant request is equivalent to ignoring it; the tool always runs under the session's current effective mode.
## Installation
```bash
npm install @deepseek-ai/dsh-escalation-tolerance
```
The package includes a Cordis patch (`cordis.patch.yml`) that registers the plugin automatically when bundled with the `@deepseek-ai/cordis` bundle system.
If you are using Cordis manually, add the plugin to your configuration:
```js
import { App } from '@deepseek-ai/cordis';
import * as escalationTolerance from '@deepseek-ai/dsh-escalation-tolerance';
const app = new App();
app.plugin(escalationTolerance);
```
## How It Works
The plugin listens on the `tools/execute` event and:
1. Extracts `sandbox_permissions` from the tool call arguments.
2. Resolves the session’s effective sandbox mode using the `sandboxPolicy` service.
3. Compares the requested mode against the `WIDER_MODES` table:
| Current mode | Allowed wider modes |
|--------------|--------------------------------------|
| `read-only` | `workspace-write`, `danger-full-access` |
| `workspace-write` | `danger-full-access` |
4. If the requested mode is **not** in that list, the plugin:
- Copies the arguments,
- Deletes `sandbox_permissions` and `justification`,
- Replaces `exec.arguments` with the sanitised copy,
- Lets the tool execute normally.
5. If the requested mode **is** in the list, the plugin does nothing – the escalation request proceeds through the usual approval flow.
If no sandbox policy is available (or resolution fails), the plugin silently bypasses and lets the call proceed.
## Dependencies
- `@deepseek-ai/cordis` (peer dependency, `^4.0.1`)
- The `sandboxPolicy` service (provided by `@deepseek-ai/dsh-sandbox` or a compatible implementation)
## License
MIT
Install
dsh plugin --profile web add github:ericleoo/dsh-escalation-tolerance
Profile: web
With the hub plugin installed, ask your agent to install it by name — it resolves the same plan shown here.
dsh plugin --profile web add github:stvlynn/dsh.fish#path:packages/dsh-plugin-hub
install deepseek-ai-dsh-escalation-tolerance from the hub
- This source has no pinned commit, so a later push upstream changes what installs. Prefer pinning a commit.