dsh-workspace-acl-allow 怎么安装？

在已安装 dsh CLI 引擎的环境中，进入插件页复制安装命令一键执行即可；自动检查通过：npm 包已发布且 engines 声明满足基线（声明 Node >=20）；该结论来自程序自动检查，未经人工实机验证。

dsh-workspace-acl-allow 兼容性怎么样？

自动检查通过：npm 包已发布且 engines 声明满足基线（声明 Node >=20）；该结论来自程序自动检查，未经人工实机验证。

dsh-workspace-acl-allow 有中文文档吗？

已提供中文翻译 README（由 DeepSeek 最新模型翻译生成），本站可切换中英文对照阅读。

dsh-workspace-acl-allow 还在维护吗？

GitHub 6 星。最近一次上游提交在 2026/10/17。

工作区 ACL 授权 lovezi0/dsh-workspace-acl-allow

DeepSeek 客户端v0.1.1

lovezi015 天前有提交已提供中文文档扫描：含敏感能力兼容 / 相关生态

在 GitHub 查看 ↗

处理沟槽的dsh Windows 的 DACLDiscretionary Access Control…

34.2/100

综合分

GitHub 星标

480

npm 周下载

—/5

用户评分

数据截至 2026/10/18 · 周下载取自 npm 全网（含 CI / 镜像），非本站安装数；综合分由星标、活跃度与兼容性检查合成。

相关生态插件（非 dsh 原生，按其对应运行时安装）

git clone https://github.com/lovezi0/dsh-workspace-acl-allow.git

状态速览

判定依据：实装验证 · 静态安装检查 · 自动扫描 · 仓库维护状态

信任档位：已验证

是什么

生态插件

可安装，未声明 dsh 能力

装得上吗

本站已在 dsh 0.2.1-rc.2 下真实安装成功

非静态推断

L4 · 真实安装等级说明 →

安全吗

本站尚未对该插件做风险分级

暂未覆盖，不等同于无风险

还在维护吗

活跃：最近一次提交在 15 天前

档位由哪些信号合成

本站实装验证（真实安装 L4 覆盖全站；L5 为运行时冒烟或实机截图，覆盖范围小于 L4） · 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。下方各区块是它的证据明细。

验证判据与等级说明 →

社区实装还没有人打卡 · 装过的第一个就是你

安装兼容性检查✓ 自动检查通过

展开查看检查明细 ↓

以下结论由程序自动检查 npm 包、engines 声明与入口文件得出，未做人工实机验证——能装不等于用着没问题。

✓npm 包dsh-workspace-acl-allow @ 0.1.1

✓Node 引擎要求 >=20 · 基线 Node 22.19 满足

✓dsh CLI 依赖未声明 dsh 版本约束

✓入口文件main/exports/bin 已声明

验证方式：npm registry 存在性 + package.json 静态校验 · 最后检查 2026/10/28 08:37:06

安全扫描自动 · 静态分析源码

v2.7.0

🔵 扫描：含敏感能力尚无人工评估

展开查看扫描说明与证据 ↓

静态扫描发现插件具备触达本地系统的能力：执行外部命令、读写/删除本地文件、读取剪贴板或密钥类环境变量（至少其一）。这是能力清单，不是危险判定——具体能力项与证据见下方，安装前请自行判断是否需要。

读写/删除本地文件发起外部网络请求

查看扫描证据（共 6 处，展示前 6 条）

读取本地文件
lib/index.js:271
if (!existsSync(file)) return {};
读取本地文件
lib/index.js:272
const parsed = JSON.parse(readFileSync(file, "utf8"));
写入本地文件
lib/index.js:287
mkdirSync(stateDir(), { recursive: true });
写入本地文件
lib/index.js:291
writeFileSync(temp, JSON.stringify(payload, null, 2), "utf8");
写入本地文件
lib/index.js:292
renameSync(temp, file);
发起网络请求
lib/client.js:101
const response = await fetch(path, Object.assign({ cache: "no-store", credentials: "same-origin" }, init || {}));

扫描于 2026/11/2（0 天前） · 范围入口闭包 + 全包扫描 · 来源 npm 发布包

静态扫描只反映源码中出现的调用，不构成安全背书；人工评估与自动扫描相互独立、互不覆盖。

依赖的 DSH / Cordis 模块

@deepseek-ai/cordis@deepseek-ai/schemastery

给这个插件打分还没有人投票↓

用户评分

还没有人投票，来当第一个

广告精选好物

飞利浦 TAH6519 主动降噪耳机 ¥299

头戴式无线 anc 主动降噪，蓝牙连接，久戴舒适向。

·anc 主动降噪 · 头戴式无线
·价格与库存以商品页实时为准

去淘宝看看→

广告MCP 兼容手册

装完插件，给 AI 接上 MCP

Cursor、Claude Code、VS Code 逐个核对：能不能装、配置怎么写、装不上是什么原因。

·按客户端逐格核对
·结论标注依据与风险等级

查 MCP 兼容性→

界面预览

2 张 · 点击查看大图

展开完整介绍（76 字）↓

处理沟槽的dsh Windows 的 DACL（Discretionary Access Control List，自主访问控制列表）必须显式授予的问题

README

由 DeepSeek 最新模型翻译生成

dsh-workspace-acl-allow DeepSeek Harness 插件。为你显式声明的工作区目录预置一条 Windows ACL 授权，让 dsh 的文件沙箱能正常启动受限执行进程，从此不必再把会话升权到「完全访问」，也不会再弹出升权确认框。它解决什么问题沟槽的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 | 只被授予「修改」的普通目录不满足这一点，写入会以「拒绝访问」失败，执行进程启动即失败；模型随后按工具说明申请升权，于是每次都要人工确认一次。本插件在宿主进程内，为你声明过的目录补一条完全控制的授权项（其中已包含「修改属主」），让宿主自身那次写入得以通过。插件不实现宿主的授权逻辑：不处理能力标识、不写完整性标签、不改目录属主、不撤销任何权限。

展开完整文档（README 剩余 1 节）

dsh-workspace-acl-allow

DeepSeek Harness 插件。为你显式声明的工作区目录预置一条 Windows ACL 授权，让 dsh 的文件沙箱能正常启动受限执行进程，从此不必再把会话升权到「完全访问」，也不会再弹出升权确认框。

它解决什么问题

沟槽的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] |
| 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 | 授权失败项的冷却时间（毫秒），冷却内不重复尝试 |
| excludePaths | [] | 追加的排除模式（支持 与 *），只能追加内置保护项之外的内容 |

状态机

$DSH_HOME/dsh-workspace-acl-allow/state.json

卸载

dsh plugin --profile web remove dsh-workspace-acl-allow

卸载会停止后续授权，但不会撤销已经写入目录的授权项。如需清理，请针对具体目录手工移除相应的授权条目。

版本历史

- 0.1.1
- 更改插件兼容性定义为 engines.dsh
- npm publish v0.1.1
- 0.1.1-alpha.1
- 💪跟随官方移除 webRuntime 更改为 webStartup
- 💪适配deepseek harness 0.2.1-alpha.1
- 0.1.0
- 🔥dsh 新增加工作区自动授权
- 🔥UI 插件-dsh-workspace-acl-allow-工作区授权白名单
- 🔥UI 显示已授权工作区路径
- 🔥UI 支持手动新增 PATH 授权

License

MIT