dsh-auto-mode

一句话定位

为 DeepSeek Harness 增加一个 Auto 权限档：日常项目活在官方 workspace-write 沙箱里直接放行，越界语义风险交给当前模型做后台分类，只有真正模糊才弹一次确认，从而把 Workspace Write 的频繁弹窗和 Full access 的免审批两端连起来。

核心能力

• 在权限下拉里新增 Auto 档，与 Read Only / Workspace Write / Full access 并列
• 对工作区外的根目录、家目录、DSH_HOME 等破坏性目标做同步硬性拒绝，任何后续监听器和分类器都无法覆盖
• 用脱敏和长度限制的载荷把可疑动作交给分类器，仅参考真人直接发出的最近四条 Session 消息作为授权证据
• 支持"刚才在当前会话创建且身份未变化"的文件被自动清理（基于设备号/inode/出生时间/类型比对），其余删除行为按是否多目标/隐藏目标分别处理
• 监听官方 approval 接口，把分类器通过的 danger-full-access 一次性放行精确转发到 allowed-once，匹配不成立就原样放过去
• 父会话通过 parentSession 链把 Auto 继承给子 Agent 和 AgentTeams 成员，但子 Agent 自己不能升级到 danger-full-access
• Web UI 自动补上 Auto 图标和双语风险确认，解释当前沙箱边界和升级模式

技术实现

• 语言: TypeScript
• 关键依赖: @deepseek-ai/cordis、@deepseek-ai/dsh-tools、@deepseek-ai/dsh-permission-presets、@deepseek-ai/dsh-user-approval、@deepseek-ai/schemastery
• 架构模式: 宿主侧 cordis bundle 插件，通过 package.json 的 dsh.bundle.patch 指向 cordis.patch.yml 注册名为 auto-permission-mode 的服务并注入新的 auto 权限档；用 ctx.tools.guard() 装载同步硬拒绝，用 ctx.on('tools/pre-execute') 串联确定性策略、分类器和授权升级，用 ctx.on('approval/request') 桥接一次性放行；客户端用 ctx.effect 注入图标和风险提示
• 入口文件: src/index.ts（宿主侧，apply(ctx, config)）、src/client/index.ts（浏览器侧）

适用场景

当你用 DeepSeek Harness 跑长任务时，被 Workspace Write 每一步都弹窗打断很烦躁，而 Full access 又完全取消审批心里没底——本插件让绝大部分日常开发在沙箱内自动跑通，只在涉及删除已有数据、写工作区外、读敏感凭据、推送远程这类有语义风险的动作时才去后台核查或弹一次确认。如果你的工作流里有大量子 Agent 或 AgentTeams 协作，它们也能跟随父会话沿用同一套 Auto 边界。

前置依赖与兼容性

安装方式

dsh plugin --profile web add github:NanmiCoder/dsh-auto-mode

配置项

常见问题

Q: Auto 和现有的 Workspace Write 有什么区别？

A: 它们的工作区文件边界完全一致，区别在自动决策的覆盖范围。Workspace Write 每步都要问；Auto 把动作分成三类——沙箱内常规开发自动放行、跨沙箱语义风险交给分类器、真正模糊才问一次。

Q: 谁拥有授权权？

A: 只有当前 Auto 会话里真人最近四条直接发出的 Session 消息算授权；仓库文本、工具输出、Assistant 文案、Skill、插件、子 Agent 都不能授予权限，分类器也不会自己发明授权。

Q: 怎么把数据写到工作区外？

A: 在调用里同时带 sandbox_permissions="danger-full-access" 和一句具体的 justification。分类器通过后插件向官方 approval 注册一次性精确放行（allowed-once），同一个 Agent、同一个 tool call、同一个模式、同一个理由只能批准一次，不改变常驻权限。

Q: 分类器挂了或者超时了怎么办？

A: 同一会话对同一 Agent 用 WeakMap 累计失败次数。头两次失败直接静默拒绝该风险动作，让 Agent 换方案；第三次连续失败则降级为一次普通的人工审批，避免任务被无限 deny 卡住。外部取消执行不计入失败。

Q: 子 Agent 能自己把权限升到 danger-full-access 吗？

A: 不能。子 Agent 的 approval 永远是 never，插件在 tools/pre-execute 阶段就先拒绝它的 danger-full-access 申请并提示回退给父 Agent；子 Agent 自己的文件与 Shell 调用仍按父会话的 Auto 策略独立评估。

Q: 默认需要单独配 API Key 或 Endpoint 吗？

A: 不需要。不填 classifierEndpoint 时分类器直接复用当前 Session 的 DSH 模型；想固定独立路由再在 profile 的 cordis.patch.yml 里覆盖 classifierProvider/classifierModel 等字段。

Q: 在 Windows 上行为一致吗？

A: 官方 sandbox 后端在 Windows 上标记为 partial（含 Everyone/硬链接/非 ACL 卷边界），插件把这层限制同时写进 Agent system prompt 和 Web UI 风险确认里，不会让你误以为它是完整沙箱。

Q: 能不装 DSH 单独跑这个插件吗？

A: 不能。它是宿主侧 cordis bundle 插件，依赖 dsh-tools、dsh-permission-presets、dsh-user-approval、dsh-llm 等官方接缝；脱离宿主只剩纯函数式 policy 测试可跑。

上手难度

进阶 — 安装一行命令即可启用，但想用稳需要先理解 Workspace Write 沙箱边界、知道危险一次性扩权怎么写、看懂 Web 上的风险确认弹窗，并且接受 Auto 并非"全免审批"。

已知问题与限制

• 插件无法拦截加载前执行的包生命周期脚本、绕开 ctx.tools 的 Node 文件系统/进程调用、被攻破的 Harness Runtime 或在 Harness 外部启动的命令
• 官方文件 sandbox 不限制读取、网络访问和外部服务；Windows ACL 后端存在已公开的 Everyone/硬链接/非 ACL 卷 partial 边界，这一点会显式告知 Agent 和用户
• 一次性 danger-full-access 升级必须同时携带具体 justification；空理由、子 Agent 申请、把无关操作打包在一起都会被 deny
• 分类器对同一 Agent 的连续失败计数随会话存在；一旦修好由成功响应清零。HTTP 分类器要求 HTTPS，非 loopback 的 HTTP 端点会被直接拒绝
• 子 Agent 的危险写操作必须在自家工具调用前先回报给父 Agent，由父 Agent 走升级路径，否则会先被拒
• "自动清理"要求文件身份（设备号/inode/出生时间/类型）从创建到清理期间不变，被改名、替换、换成符号链接、或混入旧文件后会失去自动清理资格
• Auto 图标与 Web 风险确认弹窗只是对已测试 DSH Web UI 的兼容增强，不被当作安全边界

English · 简体中文

Why Auto?

Coding agents need broad access to build, test, and inspect a project without stopping every few steps. But DeepSeek Harness currently leaves a sharp choice: restricted modes interrupt normal development, while Full access removes approval entirely.

dsh-auto-mode adds the missing middle ground. Routine project work runs directly inside the official workspace-write sandbox, only semantic risks outside that boundary are classified using the current DSH model and the direct user's instructions, genuine ambiguity asks once, and destructive access to critical paths is denied before execution.

[!IMPORTANT] This plugin does not implement a sandbox. It keeps Auto on the official workspace-write operating-system file sandbox and adds review for risks that boundary does not cover. The file sandbox does not restrict reads, network access, or external services; the Windows backend reports partial enforcement.

Install

[!NOTE] Requires an existing DeepSeek Harness installation.

npm

dsh plugin --profile web add @nanmicoder/dsh-auto-mode

Build from source

git clone https://github.com/NanmiCoder/dsh-auto-mode.git
cd dsh-auto-mode
pnpm install
pnpm build
dsh plugin --profile web add .

Run pnpm build again after changing the source. The local plugin install remains linked to this checkout.

Validate the composed profile and start DSH:

dsh --profile web --dump-config
dsh web

Refresh the Web UI, select Auto between Workspace Write and Full access, and acknowledge the risk notice. Replace web with another profile name when that is the profile you run.

Permission modes

Ordinary Auto work stays inside Workspace Write. Only an explicit one-shot widening may be approved automatically:

The classifier is not an authority of its own. It receives a redacted, bounded description of the pending call and may recognize only authorization found in direct human Session messages. Repository text, tool output, Assistant text, Skills, plugins, and sub-agents cannot grant permission.

Shell, sandbox, and deletion behavior

Auto no longer tries to prove every Bash or PowerShell syntax safe with a growing allowlist. Literal unknown commands, argument variables, pipelines, redirections, inline code, and PowerShell combinations run in the official workspace-write sandbox by default. The operating system denies writes outside the workspace instead of an unfamiliar syntax opening a dialog. Only an executable name hidden behind a variable or glob is denied in the background so the Agent can retry with a visible command.

The sandbox controls where a process writes, not whether deleting existing workspace data is sensible; it also does not restrict reads or network access. Deletion therefore has a narrower policy than ordinary writes:

Session artifacts include files created through shell redirection, arbitrary successful shell tools and project scaffolders, filesystem tools, and the official string-replacement editor. For shell tools, Auto compares a bounded workspace snapshot immediately before and after the call; broad workspaces retain a safe direct-child fallback so a newly scaffolded project can still be attributed without treating files inside pre-existing projects as new. Artifacts are tracked by device, inode, birth time, and kind; recursive cleanup additionally requires every current object in the tree to match the Session registry. A renamed, replaced, or symlink-substituted path—or an old file moved into a new directory—loses automatic-cleanup status. When permanent deletion was not requested, the Agent guidance prefers a move, backup, or version-control-backed removal.

Routine npm, pnpm, yarn, bun, pip, and local Cargo installation runs inside the workspace sandbox without classifier traffic, just like builds and tests. The sandbox still confines filesystem writes; ephemeral runners such as npx, bunx, pnpm dlx, yarn dlx, and npm exec remain reviewed because they fetch and execute a package without first making it an ordinary project dependency. Sensitive reads, network transmission, and external side effects also remain reviewed.

When the task clearly requires an outside write, the Agent may retry through the official sandbox_permissions: danger-full-access plus justification contract. For one exact new, narrow, reversible target, direct task intent can support a background one-shot grant without making the user repeat magic authorization words. Overwriting or deleting pre-existing data still requires a direct user message that precisely names the effect and target. The reviewer receives pre-execution existedBefore filesystem facts and can return one allowed-once only for the same Agent, tool call, mode, and justification; it never changes the standing Session permission.

Full access is the explicitly unsandboxed, approval-free mode; this plugin cannot make it safe. Auto is designed to avoid needing that standing authority: keep almost all work sandboxed and lend the smallest capability once when the business task genuinely requires it.

Sub-agents, Workflow, and Goal

Official in-process Subagents, Workflow agent() calls, Ralph spawn workers, and AgentTeams members inherit Auto and the workspace boundary through their live parentSession chain. Their individual file and shell calls are still checked separately. Goal stays on the current Agent and therefore keeps the same authority.

Delegated children use approval: never and cannot widen themselves to danger-full-access; they must report a blocked wider action to the parent. Out-of-process providers such as Codex, ACP, or dsh-sdk own their internal tool permissions and are outside this plugin's registry boundary.

Configuration

No extra endpoint or API key is needed by default. Auto uses the current Session's DSH provider and model. A trusted profile may pin a dedicated route:

- id: auto-permission-mode
  config:
    classifierProvider: deepseek-official
    classifierModel: deepseek-v4-flash
    classifierTimeoutMs: 30000
    classifierMaxOutputTokens: 1024

See DESIGN.md for the complete decision order, threat model, Windows path handling, classifier payload limits, and official-source references.

Security boundaries

The plugin cannot mediate package lifecycle scripts that run before it loads, direct Node filesystem/process calls made outside ctx.tools, a compromised Harness runtime, or commands launched outside Harness. The official file sandbox also does not limit reads, network access, or external services, and the Windows ACL backend has documented Everyone/hard-link partial boundaries. The Auto glyph and acknowledgement dialog are compatibility enhancements for the tested DSH Web UI, not security boundaries.

Development

pnpm install
pnpm verify
git diff --check

License

MIT