为 DeepSeek Harness 提供先询问后执行的审批:每次 write / edit…
32.2/100
综合分
3
GitHub 星标
250
npm 周下载
—/5
用户评分
数据截至 2026/9/29 · 周下载取自 npm 全网(含 CI / 镜像),非本站安装数;综合分由星标、活跃度与兼容性检查合成。
安装命令 · 需先装 dsh CLI 引擎
dsh plugin --profile web add dsh-edit-approvalnpm 源 · dsh-edit-approval 的发布者账号已校验与本仓库一致
状态速览
判定依据:实装验证 · 静态安装检查 · 自动扫描 · 仓库维护状态信任档位:仅索引
是什么
dsh 原生插件 · market
安全吗
本站尚未对该插件做风险分级
暂未覆盖,不等同于无风险
还在维护吗
更新放缓:最近一次提交在 36 天前
档位由哪些信号合成
本站实装验证(真实安装 L4 覆盖全站;L5 为运行时冒烟或实机截图,覆盖范围小于 L4) · 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。 下方各区块是它的证据明细。
社区实装还没有人打卡 · 装过的第一个就是你
安装兼容性检查✓ 自动检查通过展开查看检查明细 ↓
以下结论由程序自动检查 npm 包、engines 声明与入口文件得出,未做人工实机验证——能装不等于用着没问题。
✓npm 包dsh-edit-approval @ 0.4.0
✓Node 引擎要求 ^22.19.0 || >=24.0.0 · 基线 Node 22.19 满足
✓dsh CLI 依赖未声明 dsh 版本约束
✓入口文件main/exports/bin 已声明
验证方式:npm registry 存在性 + package.json 静态校验 · 最后检查 2026/10/21 20:37:43
安全扫描自动 · 静态分析源码v2.7.0🟢 扫描:未发现敏感能力尚无人工评估展开查看扫描说明与证据 ↓
安全扫描自动 · 静态分析源码
v2.7.0静态扫描未发现敏感能力:最多只发网络请求、读取自身元数据或只读文件,未发现执行命令、文件写入或敏感信息读取。
扫描于 2026/11/3(1 天前) · 范围 入口闭包 + 全包扫描 · 来源 npm 发布包
静态扫描只反映源码中出现的调用,不构成安全背书;人工评估与自动扫描相互独立、互不覆盖。
依赖的 DSH / Cordis 模块
@deepseek-ai/cordis@deepseek-ai/dsh-client-locale@deepseek-ai/dsh-client-store@deepseek-ai/dsh-client-ui-plugin-manager@deepseek-ai/dsh-client-ui-primitives@deepseek-ai/dsh-client-ui-settings@deepseek-ai/dsh-client-ui-slots@deepseek-ai/dsh-commands@deepseek-ai/dsh-fs@deepseek-ai/dsh-settings@deepseek-ai/dsh-tools@deepseek-ai/schemastery给这个插件打分还没有人投票↓
用户评分
还没有人投票,来当第一个
功能亮点
- 逐操作审批门
DeepSeek Harness 的逐次编辑审批门,write/edit/stream 操作执行前先做红绿行级 diff 审查 · DSH 插件
最近更新
在 GitHub 查看全部 →v0.4.02026-09-28内容较长已截断
· 0.4.0 — DSH 0.1.7 系列
dsh-edit-approval@0.4.0 发布说明。
---
· 兼容性 — 先读这里
| | |
| --- | --- |
| 支持的 DSH 范围 | 仅 0.1.7 系列 |
| 验证环境 | @deepseek-ai/*@0.1.7-rc.2 — 该系列最新版,也是本次发布在 devDependencies 中锁定的版本 |
| 声明方式 | peerDependencies:每个 harness 包一条 ^0.1.7-rc.1 元组;dsh.engines.dsh = ">=0.1.7-rc.1" |
| 更早系列 | 拒绝 — DSH 启动时跳过该 bundle,并给出 peer 诊断 |
| Node.js | ^22.19.0 \|\| >=24.0.0 |
^0.1.7-rc.1 同时覆盖 0.1.7-rc.1 和 0.1.7-rc.2:同一元组的预发布滚动无需改 peer。下限留在 rc.1,因为两者都验证过,node scripts/check-dsh-version.mjs 报告 covered: 2/27 … ceiling 0.1.7-rc.2。
本次发布在 DSH 0.1.6 及更早版本上不工作,也没打算工作。DSH 0.1.7 把本插件两个功能共用的 settings-namespace 注册表换成了每个配置档条目一个实时 Config,并移除了浏览器端 dsh-client-runtime 包和 settingsScope 服务。旧模型没有 1:1 的继任者,所以同时跟踪旧系列意味着维护两套设置模型、两条客户端写入路径和两种会话读取形态。插件一次只跟踪一个系列。
关于两套 semver 规则,容易混淆,说明一下:npm 只有在范围携带同一 [major, minor, patch] 元组上的比较符时才匹配预发布候选,所以 npm 会要求每个元组一个 || 项。DSH 的启动门用 includePrerelease 求值,所以单个 ^0.1.x-pre 项已经覆盖整个 0.1 系列。因此并集在门上不会收窄任何东西,只会夸大验证过的范围。完整推理见 docs/compat/0.1.7-audit.md §1。
· 破坏性变更
edit-approval 和 bash-approval 设置命名空间没了。两个功能现在都挂在一个配置档条目上——即 bundle 补丁插入的 dsh-edit-approval 行——每个键都改了名:
| 旧命名空间 | 旧键 | 新键 | 位置 |
| --- | --- | --- | --- |
| edit-approval | enabled | editEnabled | 插件面板 |
| edit-approval | tools | editTools | 配置档文件 |
| edit-approval | minDiffLines | editMinDiffLines | 配置档文件 |
| edit-approval | includeCreate | editIncludeCreate | 配置档文件 |
| edit-approval | includeDelete | editIncludeDelete | 配置档文件 |
| bash-approval | enabled | bashEnabled | 插件面板 |
| bash-approval | tools | bashTools | 配置档文件 |
| bash-approval | allow | bashAllow | 配置档文件 |
alwaysAllow(f182d92 中移除)保持移除。
你的设置不会迁移。DSH 把旧 settings.yaml 段导入同名条目,而两个旧名都不是配置档条目 id——所以这些段会被记录并留在 settings.yaml.imported 里。在配置档补丁里重述你原来的设置,或在新面板上设一次:
· 配置档的 cordis.patch.yml
· id: dsh-edit-approval
name: dsh-edit-approval
config:
bashEnabled: true
· 变更内容
· 侧边栏插件面板中 bundle 页上的配置面板,取代原来的两个设置 → 通用行。它用 harness 自带的分阶段表单(SettingsForm + Switch),改动先预览,点保存才写入。面板上只出现两个总开关;其余六个键仍留在配置档文件里,和以前一样。
· 实时开关。两个开关是条目仅有的实时字段:立即生效,无需重启。开关写回默认值会被清除而非固定,所
v0.3.22026-09-10
· 兼容性
· 现在声明支持 DSH 0.1.5-rc.1。七个 @deepseek-ai/dsh-* peer 全部带上四元组并集 ^0.1.0-rc.6 || ^0.1.1-rc.2 || ^0.1.2-rc.1 || ^0.1.5-rc.1(@deepseek-ai/dsh-settings 保留自己的 ^0.1.0-rc.8 下限)。npm 的预发布规则只接受与比较器共享同一 [major, minor, patch] 元组的候选版本,而「0.1.x 各线的所有预发布」没有简写形式(>=X.Y.Z-pre =0.1.0-rc.6」现在声明了运行时下限,插件管理器把它当作更新守卫来读取。
· 只改了声明。0.1.5 线本来就照常运行,已发布的 lib/ 和 src/ 与 0.3.1 逐字节相同。0.1.2 的 alpha 线和未经实测的 0.1.3-alpha.2 发布落在声明窗口之外——客户端仍按能力是否存在来分发,从不解析版本字符串。
· 变更
· npm run check:dsh 守护的是声明,而不只是最新的 dist-tag。它现在要求七个 DSH peer 的有序元组序列完全一致,把 dsh.engines.dsh 与声明的最老下限对齐,并按窗口对全部已发布版本分类——超出上限 exit 1,声明漂移 exit 3,registry 不可达 exit 2——这样像 0.1.3-alpha.2 这种未声明的线就再也溜不过去。它还修掉了一个边界情形:窗口为空时仍报告 OK。
· 文档
· README 写明了声明的四元组窗口、引擎下限,以及哪些发布落在窗口之外。
完整变更日志:
v0.3.12026-08-31
· 修复
· 恢复 DSH 0.1.2-alpha.2 的跨版本兼容——客户端改用双通道读取会话/聊天(rc.2 读会话面快照,alpha.1+ 经懒 ctx.get 读 uiConversation 的 "chat" 视图),编辑审批的红绿 diff 和 Settings → General 开关在 alpha.2 上重新可用。命令审批不受影响,它不需要客户端增强。
· 双通道读取重新启用了会话快照拆分弄坏的两个功能:审批面板上逐行重建 diff,以及设置开关的持久化(此前它的写入在 /approval-* 命令运行前就在 chat 上抛错,宿主从未存下改动)。
· 宿主侧的 settingsNamespace 改为版本中立(namespace import + settingsNamespace?.() ?? name),这样静态命名导入在 alpha.2 上不会链接失败;verify-host 增加守卫,防止回退。
· peer 范围放宽到 0.1.2 元组并集(^0.1.0-rc.6 || ^0.1.1-rc.2 || ^0.1.2-alpha.2),这些包在 alpha.2 宿主上能正常解析。
· 兼容性
· DSH rc.2(0.1.1-rc.2)/ 0.1.2-alpha.1 / 0.1.2-alpha.2;Node ^22.19.0 || >=24.0.0;DeepSeek Harness web profile。
· 版本探测看能力是否存在(ctx.get('uiConversation')、会话面 chat/pending),从不解析版本字符串。
Full Changelog:
数据来自仓库的 GitHub Release,可能与插件实际版本不一致。
README
由 DeepSeek 最新模型翻译生成dsh-edit-approval
为 DeepSeek Harness 提供先询问后执行的审批:每次 write / edit 调用都在文件真正落盘前先询问——弹出红绿行级 diff,同意一次 / 拒绝——每次 bash 命令执行前也先询问,两者各自的总开关位于侧栏「插件」面板里本插件的页面上。
npm version
npm license
刻意保持聚焦,只做一件事:两扇镜像对称的审批门——编辑与命令——让 agent 未经你同意就无法改动文件或执行命令。
| 审批门 | 拦截目标 | 默认 | 面板 |
| 编辑审批 | write / edit(str_replace_editor 需自行选入) | 开 | 红绿行级 diff——同意一次 / 拒绝 |
| 命令审批 | bash | 关 | 描述 headline + 原生命令行 |
两扇门共用 harness 自带的 serviceAsk seam:插件在 tools/pre-execute 返回 { kind: 'ask', reason },harness 将其路由进 Web 审批面板——host 端零 UI 改动——allowed-once 继续执行、rejected 拒绝调用;在 never 策略下插件直接委托,全权会话照常工作。
展开完整文档(README 剩余 1 节)
dsh-edit-approval
为 DeepSeek Harness 提供先询问后执行的审批:每次 write / edit 调用都在文件真正落盘前先询问——弹出红绿行级 diff,同意一次 / 拒绝——每次 bash 命令执行前也先询问,两者各自的总开关位于侧栏「插件」面板里本插件的页面上。
npm version
npm license
刻意保持聚焦,只做一件事:两扇镜像对称的审批门——编辑与命令——让 agent 未经你同意就无法改动文件或执行命令。
| 审批门 | 拦截目标 | 默认 | 面板 |
| 编辑审批 | write / edit(str_replace_editor 需自行选入) | 开 | 红绿行级 diff——同意一次 / 拒绝 |
| 命令审批 | bash | 关 | 描述 headline + 原生命令行 |
两扇门共用 harness 自带的 serviceAsk seam:插件在 tools/pre-execute 返回 { kind: 'ask', reason },harness 将其路由进 Web 审批面板——host 端零 UI 改动——allowed-once 继续执行、rejected 拒绝调用;在 never 策略下插件直接委托,全权会话照常工作。
效果预览
所有写类调用先弹出红绿 diff 面板;开启命令审批后,每条命令先弹出面板:白色 headline 是 agent 的描述,灰色行是命令原文。两个总开关位于侧栏「插件」面板里本插件的页面上,走 harness 自带的表单暂存(截图为 v0.4.0)。
编辑审批面板——红绿行级 diff 命令审批面板——描述 + 命令
总开关在侧栏「插件」面板里本插件的页面上 /approval-edit 与 /approval-bash 命令
安装
dsh plugin --profile web add dsh-edit-approval
装完重启 dsh web(--profile web)生效。
给贡献者:可从本地 checkout、pin 的 commit 或离线 tarball 安装——dsh plugin --profile web add /path/to/dsh-edit-approval、dsh plugin --profile web add github:SiriLee/dsh-edit-approval# 或 npm pack 后 dsh plugin --profile web add ./dsh-edit-approval-.tgz。git 安装首次会失败:pnpm 默认禁止 git 依赖执行构建脚本,需先在 profile 的 pnpm-workspace.yaml 加 allowBuilds;之后 pnpm 会执行插件的 prepare 并装入 profile。npm pack 同样运行 prepare,tarball 内始终包含预构建 lib/(含 .d.ts)与 LICENSE。
使用
1. 编辑审批默认开启。 任何 write / edit 调用都在文件被触碰前先询问。面板只显示改动行——删除红色、新增绿色——带右对齐 NN| 行号 gutter,被跳过的上下文与 hunk 间隔以 … 省略号标记。
2. 同意一次 / 拒绝。 allowed-once 放行该调用;rejected 拒绝并反馈给模型。
3. 命令审批默认关闭——在本插件页面上或通过下面的命令开启。面板白色 headline 是描述(如 bash · push to remote);下方灰色行是命令原文,由 harness 原生渲染。
4. 命令行入口: /approval-edit on|off|status 与 /approval-bash on|off|status——与该面板写同一份文档,两者不可能不一致。
5. 白名单(仅配置文件): bashAllow 存放始终放行的命令前缀。匹配做了空白归一化(git push 命中 git push),无法用多余空格绕过。暂不提供 UI。
原理
插件监听 tools/pre-execute 瀑布(harness 在工具执行前的 seam),按工具名分派到两扇门之一——名称重叠时编辑门优先。
1. 编辑审批
对每个被拦截的写类调用:
1. 解析目标文件:经 ctx.fs 解析路径,使用 fs 工具所写的会话 cwd 原文(DSH 0.1.7 起 fs 工具不再对含 .. 的 cwd 做规范化,本预览同样不做)。
2. 读取当前内容,并按各工具自身的语义从参数重建"拟写入内容":write——全文;edit——单次唯一替换(或 replace_all);str_replace_editor——str_replace 唯一替换、insert 按行插入、create 取 file_text。
3. 计算行级 diff:用 jsdiff 的 structuredPatch(Myers),与 harness 写类结果卡片同一个参考实现、同一个 3 行上下文窗口——因此审批预览与批准后的结果卡片同源,大文件里改一行就只显示一行。
4. 返回 { kind: 'ask', reason }:首行是摘要(tool · file (op): N insertions, M deletions),其后是 diff 文本。harness 的 serviceAsk 将其经 ctx.approval 路由进 Web 审批面板。
2. 命令审批
纯判定,完全不碰 fs——既不读也不写:
- 以下情况直接放行:门已关闭、工具不在 bashTools 中、命令为空、或该调用是沙箱提权(带 sandbox_permissions + justification,它们自带审批,不能重复询问)。
- 白名单优先:空白归一化后的前缀命中即放行。
- 否则返回 { kind: 'ask', reason },只有一行 headline——bash · (描述为空时就是 bash)。命令原文不写进 reason:harness 会在面板的命令行里原生渲染,避免重复。
3. 共享策略处理
会话审批策略(ask / never)始终生效。在 never 下(如 danger-full-access),本插件发出的每个 ask 都会被审批服务确定性拒绝,从而静默打断全权会话里的所有编辑与命令——所以两扇门都改为经 next() 委托,交由沙箱执行。插件绝不扩大权限,也不改动沙箱模式。
4. 审批面板
浏览器半边(dsh.client)在面板出现时增强它(按动画帧合并的 MutationObserver,所有副作用都在单个 ctx.effect 内,卸载 / HMR 时拆除):
- 编辑面板:从纯文本 headline 重建为只有改动行——删除红色、新增绿色、右对齐 NN| gutter——并附 white-space: pre-wrap 补偿,多行 diff 再加一个折叠按钮。
- 命令面板:保持 harness 原生外观,只加一个 dsh-ea-kind-command 标记,不重排样式、不重建——白色描述 headline 与灰色命令行就是 harness 渲染的样子。
配置
本插件的全部配置就是一个 profile 条目——bundle patch 插入的 dsh-edit-approval 行——分层为 schema 默认值 从 0.3.x 升级。 edit-approval 与 bash-approval 两个设置命名空间已不存在,键名改为上面的扁平字段。DSH 的设置服务会把旧 settings.yaml 的 section 导入同名条目,而这两个旧名字都不是 profile 条目 id,因此不会迁移*。若你此前开着命令审批,请在 profile patch 里写上 bashEnabled: true(或在该面板拨一次)。
明确不做的事
- 不绕过也不扩大沙箱——从不改动沙箱模式或授予权限;提权调用交给沙箱自己的审批。
- 不拦截命令内部——在 bash 命令里发生的文件改动不由编辑门管辖(开启命令审批后由它覆盖)。
- 不做部分应用——diff 是只读预览(+ / - 行标记),不支持"只应用其中几行"。
- 不对工具本身会失败的调用提问——例如对已存在文件执行 str_replace_editor create、old_str / old_string 缺失或不唯一;这些直接放行,由工具自己报错。空的 old_string 编辑预览与工具行为有偏差(按"未找到"处理)——这是安全的,绝不会误拦。
- 不做快捷键(Enter 批准 / Esc 拒绝)——已拆到独立的 dsh-approval-hotkeys 插件。
- 不做改后复查 / 回滚——见社区插件 dsh-change-review。
- 不扩展权限层级——见社区插件 dsh-auto-approval-plugin。
兼容性
- Node.js ^22.19.0 || >=24.0.0。
- DeepSeek Harness web profile(dsh --profile web);@deepseek-ai/ 由 harness 在运行时解析,本包不会自行拉取。
- 仅支持 DSH 0.2.0 这一条线——验证目标是 0.2.0-rc.1,也是本次发布 devDependencies 钉住的版本。声明为每个 harness 包一个 ^0.2.0-rc.1 peer 元组,以及 engines.dsh = ">=0.2.0-rc.1"。本插件一次只追一条 DSH 线,线一移动就丢掉上一条:该范围放行 0.2.0-rc.1 至 0.2.x(同元组的预发布滚动无需改动 peer),而 0.1.7-rc.2 与 0.3.0-rc.1 会在启动时被跳过并给出 peer 诊断,而不是加载成半坏状态。
- node scripts/check-dsh-version.mjs 盯发布节奏:校验声明自洽(各 harness peer 同一元组、engine floor 同步),并在 DSH 发布了声明窗口之上的版本时报告。
- 为什么是单线。 DSH 0.1.7 把本插件两扇门共用的设置命名空间注册表换成了"每个 profile 条目一个 live Config",同时删除了浏览器侧 dsh-client-runtime 包与 settingsScope 服务。旧模型没有 1:1 后继,因此同时兼容更早的线意味着维护两套设置模型、两条客户端写路径与两种会话读取形状。逐 seam 的完整记录(包括哪些失效是静默的)见 docs/compat/0.1.7-audit.md。
- 注册的工具名是 str_replace_editor(下划线),与 npm 包名 @deepseek-ai/dsh-tool-str-replace-editor 不同。
[!WARNING]
本项目与 DSH 均处于开发者预览阶段。请在可复现环境中 pin 精确版本,并留意上述行为说明。
安全
插件只在 tools/pre-execute 拦截点读取目标文件以计算编辑预览;命令门完全不碰文件。它自己从不写文件——工具主体只在你批准后才执行写入。它不发起网络请求,也不访问任何凭据。
开发
npm install # 装 devDeps(harness 包精确钉到目标线)
npm run typecheck # 对两套编译面做 tsc,跑在真实 DSH 类型上
npm test # vitest:diff / guards / config / integration / client / package-layout
npm run build # scripts/build.mjs:声明 + 两个产物 + 冒烟检查
npm run verify:host # 在真实 cordis Context 上驱动已构建的 host 产物
npm run check # typecheck + tests + build + verify:host + npm pack --dry-run
prepare 会跑构建,因此 git 安装与 npm pack / npm publish 始终产出完整的 lib/(含 .d.ts)与 LICENSE。
其中两步的存在,是因为让本插件整整报废一条 DSH 线的两种失效都是静默的:
- 构建会被自己的冒烟检查拦住:客户端产物不允许内联任何 node_modules 输入(经 esbuild 的 metafile 检查),所以 externals 列表漏掉一个平台模块会让构建失败,而不是悄悄打进第二份 React;同时两个产物都不得引用目标线已删除的包。
- verify:host 把 settings 替身双向锚定到真实的 SettingsForms.prototype。此前那个替身只实现了一个方法——settings.register,恰好是 0.1.7 删掉的那一个——于是套件与插件互相印证、与真实世界无关,绿着穿过了它本该拦住的那次断裂。
发布
发布走 GitHub Actions Trusted Publishing(OIDC,不存 NPM_TOKEN)。见 docs/npm-trusted-publishing-guide.md。
npm version patch && git push origin main --tags # 触发 .github/workflows/publish.yml
工作流会校验 tag 与 package.json 一致,跑 typecheck + 测试 + 完整构建 + 产物校验,带 Sigstore provenance 发布,并创建 GitHub Release。CI(.github/workflows/ci.yml)在每次 push / PR 上跑同样的检查。发布步骤是幂等的——npm 上已存在的版本会被跳过。
许可
MIT预览分享卡片长什么样 ↓
分享 · DeepSeek Harness Hub
SiriLee/dsh-edit-approval
为 DeepSeek Harness 提供先询问后执行的审批:每次 write / edit…
相关插件 · 市场 / 管理
插件精选列表awesome-dsh-plugin/awesome-dsh-plugin
DeepSeek Harness(dsh)插件精选列表
★ 22,225未汉化DSH
73.6
新词雷达zhuyansen/new-term-radar
new-term-radar新词雷达
★ 2,049已汉化MCP
72.8
插件生态导航0xsline/awesome-deepseek-harness
安装 贡献指南 DeepSeek Docs 公开插件目录 Issues
★ 1,188已汉化DSH
72.6
技能注册中心iflytek/skillhub
企业级开源智能体技能注册中心——发布、发现并管理组织内可复用的技能包。
★ 5,370已汉化DSH
71.9
插件市场目录imsai-sh/awesome-deepseek-harness-plugins
面向 DeepSeek Harnessdsh生态的社区插件目录,共收录 13941 个插件含 PR 收录与…
★ 355已汉化DSH
71.8
插件精选清单Anil-matcha/awesome-dsh-plugin
DeepSeek Harnessdsh精选指南——DeepSeek…
★ 1,013已汉化DSH
71.7
这是你的仓库?认领条目