DeepSeek Harness 报 not strictly wider？DSH plugin 沙箱权限升级被拒排查

DeepSeek Harness 反复报 not strictly wider、工具调用被拒，根因是沙箱升级校验把「同级权限」当成了「非法升级」：工具 schema 静态广告了一批升级目标，而权限阶梯表里没有最高权限这一档，已达最高权限的会话再带升级参数重试时，校验器找不到更宽的目标，只能拒绝。 让重试请求不带 sandbox_permissions，就能立刻绕开。

DeepSeek Harness not strictly wider 报错是什么样

报错在权限最高的会话里最明显：明明已经是 danger-full-access，升级参数还在刷屏、重试仍被拒。 有用户实跑遇到（讨论原文），典型表现有三种：

1. 工具调用被拒并提示 not strictly wider，但当前模式已经是最高权限；
2. 模型反复尝试带 sandbox_permissions 的重试，界面里同一段升级参数反复出现，形成刷屏（讨论原文）；
3. 同级权限的重试同样被拒——请求想要的档位和当前档位一样，本该视为空操作放行，却被判为非法（讨论原文）。

三种表现同源，所以处理方式也一致：先看当前权限档位，再看请求带的升级参数，多数情况是两者本来就相等。

DSH plugin 沙箱升级为什么被判为 not strictly wider

机制有两层缺陷叠加：参数广告不随模式收窄，权限阶梯表又缺最高档。 拆开看：

1. 工具 schema 会静态广告升级目标参数，不随当前权限模式动态收窄，于是模型始终看得到「可以升级」的选项；
2. 校验器内部的 WIDER_MODES 阶梯表没有 danger-full-access 这一档的条目，已达最高权限时找不到「更宽」的目标；
3. 消费端的 validateEscalationArgs 还会在更早一步拦截，所以即便请求本身合法，也会先被判为非法升级；
4. 社区给出的正解是让 normalizeEscalationMode 先解析会话的常驻权限策略，把同级请求按空操作放行，同时让 schema 按当前模式动态收窄（来源）。

一句话概括：问题不在权限不够，而在校验器只会做「更宽」的判断，不会做「相等」的判断。这套误判对 DSH插件 和 DeepSeek插件 一视同仁：校验发生在运行时权限层，插件侧再怎么写参数也改变不了阶梯表的缺项。

DSH plugin 场景下 not strictly wider 怎么规避，修复到哪一步

规避思路是别让请求看起来像一次升级。 按可控程度排序：

1. 让重试请求不带 sandbox_permissions 参数：模型侧不再声明升级意图，校验层直接放行；
2. 从最高权限模式回退到普通模式再执行同一操作：普通模式下阶梯表存在可比对象，不会落到「找不到更宽档位」的分支；
3. 排查时确认三件事：当前权限档位、请求声明的目标档位、是否带升级参数——三者一致时被拒，就是本文描述的同级误判；
4. 需要对照插件行为时，可在「设置 → 插件市场」核对已装插件与权限相关配置，本项目的社区插件市场入口是 DSH Plugin Hub；
5. 修复进度：已有多个社区补丁分支和一个社区插件给出了实现，但都未合入，升级到含修复的版本前该报错仍会出现。

DSH plugin 排查注意事项

别把 not strictly wider 当插件问题，也别靠继续提权来「把请求放过去」——触发条件是同级请求被误判，与插件无关，提权只会放大风险。 三条要点：

1. 这不是插件兼容性问题：校验发生在权限层，与插件是否支持沙箱升级无关，换插件或重装插件都不会生效。
2. 不要为了「让请求通过」而不断放宽权限：真正的触发条件是「同级请求被误判」，继续提权只会让会话暴露在更高风险里。
3. 其他运行时与界面报错还汇总在《DeepSeek Harness 报错合集：从安装到运行时的排查入口》，可对照查看。

来源：Discussion #201、Discussion #468、Discussion #4359