Fix sandbox "not strictly wider" in DeepSeek Harness

DeepSeek Harness repeatedly reporting not strictly wider and rejecting tool calls comes down to the escalation validator treating a same-level permission request as an illegal upgrade: tool schemas advertise escalation targets statically, the wider-mode table has no entry for the top tier, and a session already at full access that retries with escalation parameters finds no wider target, so it is rejected. Sending the retry without sandbox_permissions clears it immediately.

What the DeepSeek Harness not strictly wider error looks like

It shows up most clearly in the highest-permission sessions: even at danger-full-access, escalation parameters keep appearing and retries keep being refused. A user hit this in the wild (see the discussion), with three typical shapes:

1. A tool call is rejected with not strictly wider while the session is already at the top permission mode;
2. The model keeps retrying with sandbox_permissions, so the same escalation block scrolls past again and again (see Discussion #468);
3. A same-level retry is rejected too — the requested tier equals the current tier and should be a no-op, yet it is treated as an illegal upgrade (see Discussion #4359).

All three share one origin, and so does the fix: check the current permission tier, then check the escalation parameters on the request — in most cases the two are already equal.

Why a DSH plugin sandbox escalation hits "not strictly wider"

Two defects stack: parameters are not narrowed to the active mode, and the permission ladder is missing its top entry. Broken down:

1. Tool schemas advertise escalation target parameters statically, so the model always sees an upgrade option no matter which mode is active;
2. The internal WIDER_MODES ladder has no entry for danger-full-access, so at the top tier there is no "wider" target to find;
3. The consumer-side validateEscalationArgs intercepts even earlier, so an otherwise legal request is rejected before it is evaluated properly;
4. The community's fix is to have normalizeEscalationMode resolve the session's standing policy first, treat same-level requests as a no-op, and narrow the schema to the current mode (source: Discussion #4359).

In one line: the validator only knows how to answer "is this wider?" and never "is this the same?"

How to work around not strictly wider in DeepSeek Harness, and where the fix stands

The guiding idea is to stop the request from looking like an upgrade.

1. Send the retry without sandbox_permissions: with no declared escalation intent, the validation layer lets it through;
2. Drop from the top permission mode to a normal mode and repeat the action: a normal mode has a comparable tier in the ladder, so the "no wider target" branch is never reached;
3. While diagnosing, confirm three things: the current tier, the target tier in the request, and whether escalation parameters are attached — when all three agree and the call is still refused, you are looking at this same-level misjudgement;
4. To compare plugin behaviour, review installed plugins and permission-related settings under Settings → Plugin Marketplace; the community marketplace for this project is DSH Plugin Hub;
5. On the fix: several community branches and one community plugin implement it, but none is merged, so expect the error to persist until you upgrade to a build that contains the change.

DSH plugin troubleshooting notes

Do not read not strictly wider as a DeepSeek Harness plugin problem, and do not widen permissions to push the request through — the trigger is a same-level request being misjudged, and more access only adds risk. Three points:

1. This is not a plugin-compatibility problem: validation happens in the permission layer and does not care whether a plugin supports sandbox escalation, so switching or reinstalling plugins does nothing.
2. Do not keep widening permissions just to make requests pass: the trigger is a same-level request being misjudged, and granting more access only exposes the session to more risk.
3. Other runtime and UI failures are collected in DeepSeek Harness troubleshooting: entry points from install to runtime.

Sources: Discussion #201, Discussion #468, Discussion #4359