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]
Plugin 0.1.7 supports the exact Harness versions below. The recommended host is 0.1.2-rc.1, which remains a host prerelease. Updating the plugin does not upgrade the running host. Mixed DSH dependency cohorts are unsupported.
| Harness host |
Plugin |
Pair |
0.1.2-rc.1 |
0.1.7 |
Recommended |
0.1.2-alpha.5 |
0.1.7 |
Compatible |
0.1.2-alpha.3 |
0.1.7 |
Retained compatibility |
0.1.2-alpha.2 |
0.1.7 |
Retained compatibility |
0.1.1-rc.2 |
Historical 0.1.5 |
Unsupported by 0.1.6/0.1.7; migrate to a pair above for redundant sandbox recovery |
| Other versions |
Undeclared |
Require full host validation first |
compatibility.json defines the exact matrix. See the maintenance record for diagnosis, migration and fixes, and the historical Alpha acceptance report for earlier evidence.
npm
Check the actually running dsh --version, then install the exact plugin:
dsh plugin --profile web add --save-exact @nanmicoder/[email protected]
latest carries stable plugin releases; next carries plugin prereleases. Neither tag implies arbitrary host compatibility. Git source installs build through prepare and require development dependencies and enabled install scripts. Registry packages already contain compiled output.
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.
The Web client registers its copy with DSH's official locale service. English keeps the Auto product label; Chinese shows 自动审批. Switching the DSH language updates the permission menus, active-mode control, General-settings selector, /permission picker description, and acknowledgement dialog without a restart.
Permission modes
| Mode |
File sandbox |
Approval |
Auto policy |
| Read Only |
read-only |
ask |
inactive |
| Workspace Write |
workspace-write |
ask |
inactive |
| Auto |
workspace-write |
ask |
active |
| Full access |
danger-full-access |
never |
inactive |
Ordinary Auto work stays inside Workspace Write. Only an explicit one-shot widening may be approved automatically:
| Decision |
Typical effect |
| Allow |
unfamiliar sandboxed Bash/PowerShell, routine dependency installation, local Git commits, project work, builds, tests, type checks, audited DSH coordination tools |
| Classify |
pre-session deletion, ephemeral downloaded-package execution, dangerous remote Git/database/service changes, sensitive reads, network transmission, external-system writes, exact sandbox widening |
| Ask once |
genuinely ambiguous effect or authority, or manual review after three consecutive classifier failures; an escalation reuses the official exact approval instead of opening two dialogs |
| Deny |
root/home/DSH_HOME/system destruction, policy bypass, credential exfiltration, hidden dynamic deletion, and the first two consecutive classifier failures for a risky action |
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:
| Deletion kind |
Auto behavior |
| One exact artifact created in this Session with unchanged file identity |
clean up automatically |
| One pre-existing file or directory |
classify only after a direct user message precisely requests that target |
| One pre-existing target outside the workspace |
lend one exact wider grant after precise authorization |
| Multiple targets, globs, variables, piped operands, or nested-interpreter deletion |
deny in the background and require one visible literal target per call |
| Filesystem root, Home, DSH_HOME, system, or credential-critical paths |
deny unconditionally |
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.
Ordinary calls should omit sandbox_permissions and justification. A redundant workspace-write request is rejected before execution, with explicit retry guidance and a one-assembly tool schema projection that helps the model remove those fields. Standing permissions remain unchanged. Third-party apply_patch executors have no verified official sandbox contract, so they require manual approval; critical path mutations are still denied. Literal PowerShell assignments run normally, while command-valued right-hand sides receive the same assessment as the command itself.
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 localized Auto label, 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
dsh-auto-mode 为 DeepSeek Harness（DSH）增加了一个「Auto」权限模式，介于受限的 Workspace Write 和不受限的 Full access 之间。例行的项目工作自动在沙箱中运行，只有真正有风险、超出沙箱的操作才会被分类、一次性批准或拒绝。