dsh-workspace-acl-allow
DeepSeek Harness 插件:为用户显式声明的工作区目录预置 Windows ACL 完全控制 ACE,补上沙箱授权所需的 WRITE_OWNER 前提,消除危险模式弹框。
一句话定位
DeepSeek Harness 插件:为用户显式声明的工作区目录预置 Windows ACL 完全控制 ACE,补上沙箱授权所需的 WRITE_OWNER 前提,消除危险模式弹框。
安装方式
在 DSH 的 web profile 中执行下面的命令;装完刷新页面即可。
$ dsh plugin --profile web add dsh-workspace-acl-allow@0.1.1
兼容的 DSH 版本
>=0.2.1-alpha.1
作者与热度
lovezi0 · ★ 11 · 更新于 2026-10-17
关于这个插件
dsh-workspace-acl-allow
DeepSeek Harness 插件。为你显式声明的工作区目录预置一条 Windows ACL 授权,使 dsh 的文件沙箱能够正常启动受限执行进程,从而不再需要把会话升权到「完全访问」、也不再弹出升权确认框。
[](./LICENSE) [](https://www.npmjs.com/package/dsh-workspace-acl-allow) [](https://github.com/deepseek-ai/deepseek-harness) [](#安装)
它解决什么问题
沟槽的deepseek harness从 0.1.7 起,给 grantWrite 加了 Low 完整性标签,把权限门槛抬高了。
| | ≤0.1.6 | ≥0.1.7-alpha.1 |
| --- | --- | --- |
| grantWrite 写入内容 | 只写 DACL 能力 ACE | ACE + deny + Low 强制标签 |
| 需要的目录权限 | WRITE_DAC(owner 隐式自带) | 还要 WRITE_OWNER——owner 隐式权限不含它,必须 DACL 显式授予 |
| 对继承 Modify 的目录 | ✅ 静默成功 | ❌ 必败 Win32 5 |
只被授予「修改」的普通目录不满足这一点,写入会以「拒绝访问」失败,执行进程启动即失败;模型随后按工具说明申请升权,于是每次都要人工确认一次。
本插件在宿主进程内,为你声明过的目录补一条完全控制的授权项(其中已包含「修改属主」),使宿主自身那次写入得以通过。
插件不实现宿主的授权逻辑:不处理能力标识、不写完整性标签、不改目录属主、不撤销任何权限。
如果你也遇到了已下错误则本插件可能/也许/大概能解决你的问题
| tools error | step error] |
| --- | --- |
| | |
上游 0.2.0-rc.2 已内置官方处理方式
dsh 0.2.0-rc.2 起,宿主随包内置了官方处理方式 diagnose-windows-sandbox-acl 技能:工具被权限拒绝之后,模型加载它,申请一次升权运行自带脚本,对失败路径及其祖先补上缺失的授权(每处改动有备份与回滚命令)。官方走的是踩坑后反应式自愈,本插件走的是声明时预授权——同一个病根,处理方式不同:
| | 本插件 | 上游官方技能 |
|---|---|---|
| 时机 | 工作区注册/手动声明时即完成,坑根本不会踩到 | 先踩坑(工具失败),才可能触发 |
| 审批 | 零弹框,会话全程受限执行 | 每次踩坑都要人工批准一次升权命令 |
| 触发条件 | 宿主进程级自动,与会话内容、模型判断无关 | 依赖模型遇到报错后主动加载技能并正确操作 |
| 覆盖范围 | 声明过的目录常驻生效,存量工作区一次性补齐 | 只修报错的那一条路径,换个目录就得再踩再修一轮 |
| 失败退路 | 授权失败在列表里可见、可重试 | 审批被拒或修复失败时,仍回到「完全权限」弹框 + 发反馈 |
安装
dsh plugin --profile web add dsh-workspace-acl-allow
本仓库为组合包,安装后其配置层会随 profile 一并加载。
使用
授权只在你明确表达意图时发生,有且只有两个入口:
1. 在 dsh 中添加工作区 —— 工作区记录写入后立即完成授权。插件加载之前就已注册的工作区,会在插件启动时一并补齐。
2. 在插件页手动新增路径 —— 打开「插件」页 → 本插件 → 详情页底部的「工作区授权白名单」,输入目录路径并新增。适合尚未注册为工作区的目录。
列表中的每条记录都会带回状态:
| 状态 | 含义 |
|---|---|
| 已授权 | 授权项已就位 |
| 授权失败(退出码 …) | 授权未生效;常见原因是目录属主不是当前用户,或当前用户对该目录没有修改 DACL 的权限 |
| 受保护目录,已拒绝 | 命中内置保护清单,不会被授权(见下) |
| 目录不存在 | 路径无效 |
每个条目都可以「重新授权」(忽略记录强制重跑一次)或「移除」(只删除本插件的记录,不会改动目录上已有的任何权限)。
显式原则
插件不会接管任何会话的工作目录。会话目录可以直接指向任意位置,插件不会因为在某个目录下开会话就静默放宽它的权限——这类目录需要你自己在插件页声明。这是刻意的取舍:放宽一个目录的权限属于安全敏感动作,必须由人发起。
内置保护清单
以下位置始终拒绝,无法通过配置或界面解除:
- 盘符根目录
- 系统目录(Windows 目录、程序文件目录、程序数据目录)
- 用户配置文件根目录(其下的子目录不受限)
- 回收站与系统卷信息目录
另外不接受相对路径与网络路径。
平台
仅支持 Windows。 非 Windows 平台上插件不生效(只记录一条日志)。本项目仅在 Windows 上开发与验证,没有其他平台的实测环境。
副作用
- 被处理的目录上,当前用户会从「继承的修改」变为显式的完全控制(含修改权限与属主)。以该用户身份运行的任何进程对该目录的权限随之放宽。这与 dsh 工作区模型的既有代价同源——宿主授权成功后同样会留下常驻的授权项与完整性标签。
- 授权只作用于工作区根目录一条授权项,不递归修改子项权限(除非显式开启对应配置)。
- 移除列表条目不会撤销已生效的授权;撤销由 dsh 自身的授权体系负责。
配置
配置写在 profile 的配置层中,安装后即可生效。
| 字段 | 默认 | 说明 |
|---|---|---|
| watchWorkspaces | true | 是否订阅工作区新增事件(关闭后只剩手动入口) |
| deepGrant | false | 是否递归处理子项。仅在子目录继承被破坏时开启 |
| retryCooldownMs | 3600000 | 授权失败项的冷却时间(毫秒),冷却内不重复尝试 |
同分类对比
同一分类下 Star 最高的 5 个,便于横向比较。
| 插件 | 作者 | Star | 版本 | 更新 |
|---|---|---|---|---|
| Mole | tw93 | 74.5K | 0.0.0 | 2026-11-10 |
| DeepSeek-Reasonix | esengine | 36.1K | 0.0.0 | 2026-11-10 |
| dsh-desktop | anywhere-labs | 35.6K | 0.4.1 | 2026-11-06 |
| awesome-dsh-plugin | awesome-dsh-plugin | 24.1K | 0.1.0 | 2026-11-10 |
| dsh-market | dsh-market | 11.8K | 1.73.17 | 2026-11-09 |