Skip to content
dsh.fish
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

  • This source has no pinned commit, so a later push upstream changes what installs. Prefer pinning a commit.
Source