dsh-auto-mode

One-Line Positioning

Adds an Auto permission preset to DeepSeek Harness: daily projects run directly in the official workspace-write sandbox, cross-boundary semantic risks are handed to the current model for background classification, and only truly ambiguous cases trigger a single confirmation—bridging the frequent popups of Workspace Write with the no-approval end of Full access.

Core Capabilities

• Adds an Auto option in the permission dropdown, alongside Read Only / Workspace Write / Full access
• Synchronously hard-rejects destructive targets outside the workspace such as root directory, home directory, DSH_HOME; no subsequent listeners or classifiers can override this
• Uses desensitized and length-limited payloads to hand suspicious actions to the classifier, referencing only the last four Session messages directly issued by a real human as authorization evidence
• Supports automatic cleanup of "files created in the current session whose identity hasn't changed" (based on device number/inode/creation time/type comparison), with other deletion behaviors handled separately based on multi-target/hidden-target criteria
• Listens to the official approval interface, forwards classifier-passed danger-full-access one-time passes precisely to allowed-once; passes through unchanged if no match
• Parent sessions inherit Auto to child Agents and AgentTeams members via parentSession chain, but child Agents cannot upgrade to danger-full-access themselves
• Web UI automatically adds Auto icon and bilingual risk confirmation, explaining current sandbox boundaries and upgrade modes

Technical Implementation

• Language: TypeScript
• Key Dependencies: @deepseek-ai/cordis, @deepseek-ai/dsh-tools, @deepseek-ai/dsh-permission-presets, @deepseek-ai/dsh-user-approval, @deepseek-ai/schemastery
• Architecture Pattern: Host-side cordis bundle plugin, registered via dsh.bundle.patch in package.json pointing to cordis.patch.yml to inject a service named auto-permission-mode and a new auto permission preset; uses ctx.tools.guard() for synchronous hard rejection, uses ctx.on('tools/pre-execute') to chain deterministic policies, classifiers and authorization upgrades, uses ctx.on('approval/request') to bridge one-time pass-through; client uses ctx.effect to inject icons and risk prompts
• Entry Files: src/index.ts (host-side, apply(ctx, config)), src/client/index.ts (browser-side)

Applicable Scenarios

When running long tasks with DeepSeek Harness, getting interrupted by Workspace Write popups at every step is annoying, while Full access completely removes approval leaving you uneasy—this plugin lets most daily development run automatically within the sandbox, only performing background checks or a single confirmation for actions with semantic risks like deleting existing data, writing outside the workspace, reading sensitive credentials, or pushing remotely. If your workflow has many child Agents or AgentTeams collaborations, they can also follow the parent session to use the same Auto boundaries.

Prerequisites & Compatibility

Installation

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

Configuration Options

FAQ

Q: What's the difference between Auto and existing Workspace Write?

A: Their workspace file boundaries are identical; the difference is in the scope of automatic decision-making. Workspace Write asks at every step; Auto categorizes actions into three types—routine development inside the sandbox passes automatically, cross-sandbox semantic risks go to the classifier, and only truly ambiguous cases ask once.

Q: Who has authorization authority?

A: Only the last four Session messages directly issued by a real human in the current Auto session count as authorization; repository text, tool outputs, Assistant copy, Skills, plugins, and child Agents cannot grant authorization, and the classifier won't invent authorization either.

Q: How to write data outside the workspace?

A: Include sandbox_permissions="danger-full-access" in the call along with a specific justification. After the classifier passes, the plugin registers a precise one-time pass with the official approval (allowed-once); the same Agent, same tool call, same pattern, and same reason can only be approved once, without changing the permanent permission.

Q: What if the classifier fails or times out?

A: Failures accumulate with a WeakMap for the same Agent in the same session. The first two failures silently reject the risky action, letting the Agent try another approach; the third consecutive failure downgrades to a normal manual approval to prevent tasks from being stuck in infinite denies. External cancellation doesn't count as failure.

Q: Can child Agents upgrade their permission to danger-full-access themselves?

A: No. Child Agent's approval is always never; the plugin rejects its danger-full-access request first at the tools/pre-execute stage and suggests falling back to the parent Agent; the child Agent's own file and Shell calls are still evaluated independently against the parent session's Auto policy.

Q: Do I need to configure a separate API Key or Endpoint by default?

A: No. When classifierEndpoint is not set, the classifier directly reuses the current Session's DSH model; to fix an independent route, override classifierProvider/classifierModel etc. in the profile's cordis.patch.yml.

Q: Is behavior consistent on Windows?

A: The official file sandbox backend is marked as partial on Windows (including Everyone/hardlinks/non-ACL volume boundaries). The plugin writes this limitation into both the Agent system prompt and Web UI risk confirmation, so you won't mistakenly think it's a complete sandbox.

Q: Can this plugin run without DSH installed?

A: No. It's a host-side cordis bundle plugin, depending on official seams like dsh-tools, dsh-permission-presets, dsh-user-approval, dsh-llm; away from the host, only pure functional policy testing can run.

Difficulty Level

Advanced — installation is a single command to enable, but to use it stably you first need to understand Workspace Write sandbox boundaries, know how to write dangerous one-time permission escalation, understand the risk confirmation popups on the web, and accept that Auto is not "all approval-free."

Known Issues & Limitations

• The plugin cannot intercept package lifecycle scripts executed before loading, Node filesystem/process calls that bypass ctx.tools, compromised Harness Runtime, or commands started outside Harness
• The official file sandbox doesn't limit reading, network access, or external services; Windows ACL backend has publicly known Everyone/hardlinks/non-ACL volume partial boundaries—this is explicitly communicated to Agents and users
• One-time danger-full-access upgrade must include a specific justification; empty reasons, child Agent requests, or bundling unrelated operations together will be denied
• Classifier's consecutive failure count for the same Agent persists with the session; it's cleared by a successful response once fixed. HTTP classifiers require HTTPS; non-loopback HTTP endpoints are directly rejected
• Child Agent's dangerous write operations must report to the parent Agent before their own tool calls, with the parent Agent taking the upgrade path—otherwise they'll be rejected first
• "Automatic cleanup" requires the file identity (device number/inode/creation time/type) to remain unchanged from creation to cleanup; renaming, replacing, converting to symlink, or mixing with old files will disqualify from automatic cleanup
• Auto icons and Web risk confirmation popups are merely compatibility enhancements for tested DSH Web UI and should not be treated as security boundaries

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