Foreword¶
When running a Coding Agent with DeepSeek Harness (DSH), the permission mode often presents a dilemma: only enabling “writable workspace” causes frequent pop-ups when the Agent installs dependencies, runs tests, or modifies files, interrupting the development flow. Switching to Full access eliminates approvals entirely, but if the Agent accidentally deletes files or accesses sensitive paths, the consequences are hard to reverse.
To address this gap, community maintainer NanmiCoder has introduced dsh-auto-mode (npm package name @nanmicoder/dsh-auto-mode). It adds an Auto / auto-approval mode on top of the official workspace-write sandbox—automatically approving routine project operations, delegating semantic risks beyond sandbox coverage to a classifier for review, and directly rejecting truly dangerous actions before execution. This plugin is categorized under admin-security in the SkillHub plugin library, has approximately 123 stars on GitHub, and is licensed under MIT. It has been tested with DeepSeek Harness 0.1.0-rc.6.
Please note: SkillHub (https://www.skillhub.cn/plugins) is a DSH plugin community directory for Chinese users and has no official affiliation with DeepSeek / High-Flyer. DSH itself adheres to the “everything is a plugin” philosophy, and permission strategies can similarly be extended through community plugins.
What is This¶
dsh-auto-mode’s positioning can be summarized in one sentence: Safe automatic permissions for DeepSeek Harness—providing a “sandbox-first, semantic review, minimal privilege escalation” automatic permission strategy for the Harness.
It does not implement an OS-level sandbox on its own but keeps the Auto mode resident within DSH’s official workspace-write file sandbox, supplementing it with three capabilities:
- Automatically allowing predictable routine operations within the sandbox (builds, tests, regular dependency installations, etc.);
- Calling the DSH model of the current Session for classification when semantic risks arise beyond the sandbox boundary (sensitive reads, network exfiltration, deleting pre-existing files before the Session, etc.);
- Unconditionally rejecting critical targets like root directories, Home, DSH_HOME, and credential paths.
In the Chinese Web UI, this mode displays as 「自动审批」; the English interface retains the Auto product name.
Core Features and Highlights¶
Comparison of Four Permission Modes¶
After installing the plugin, an additional Auto tier appears between “writable workspace” and “full access” in the permission menu:
| Mode | File Sandbox | Approval | Auto Strategy |
|---|---|---|---|
| Read Only | read-only |
ask | Not enabled |
| Workspace Write | workspace-write |
ask | Not enabled |
| Auto-approval (Auto) | workspace-write |
ask | Enabled |
| Full access | danger-full-access |
never | Not enabled |
Auto’s ordinary read/write operations remain confined within the Workspace Write boundary; only explicit one-time privilege escalation requests may be automatically approved.
Four Types of Decisions: Allow, Classify, Ask Once, Reject¶
For each tool call to be executed, the plugin generally falls into the following strategies (see DESIGN.md in the repository for details):
| Decision | Typical Effect |
|---|---|
| Automatically Allow | Bash/PowerShell within sandbox, regular npm/pnpm/yarn/bun/pip/Cargo installations, local Git commits, builds, tests, type checks, audited DSH collaboration tools |
| Background Classification | Deleting pre-existing data, temporary downloads and executions via npx/bunx, remote Git/database/service changes, sensitive reads, network transfers, external system writes |
| Ask Once | When the effect or authorization is genuinely unclear, or after three consecutive classifier failures, escalate to human review; reuse the official single precise approval for privilege escalation to avoid duplicate pop-ups |
| Direct Reject | Root directory, Home, DSH_HOME, system sabotage, privilege bypass, credential exfiltration, hidden dynamic deletion, and two consecutive classifier failures before risky operations |
The classifier is not an authorization source: it can only recognize authorization in direct user Session messages. Repository READMEs, tool outputs, Assistant replies, Skills, plugins, or sub-agent text cannot authorize on the user’s behalf.
Granular Strategies for Shell and Deletion¶
Auto no longer maintains a growing command whitelist. Literal unknown commands, pipes, redirections, etc., default to the official workspace-write sandbox, with writes outside the workspace rejected by the operating system. Only when executable filenames are obscured by variables or globs will it background-reject and require the Agent to rewrite the command visibly.
Deletion rules are stricter than ordinary writes: a single file created and not modified by identity in the current Session can be automatically cleaned up; deleting files that existed before the Session requires the user to explicitly name that target in the conversation; multi-target, glob, and pipe deletions are all rejected; root directory and critical credential paths are unconditionally rejected.
When a task genuinely requires writing outside the workspace, the Agent can retry via the official sandbox_permissions: danger-full-access with justification. The Reviewer can return at most one allowed-once without changing the Session’s resident permissions.
Sub-Agents and Multi-Agent Collaboration¶
Official in-process Subagents, Workflow agent(), Ralph spawn workers, and AgentTeams members inherit Auto and workspace boundaries via the parentSession chain, but each file/shell call is still checked individually. Sub-Agents use approval: never and cannot request danger-full-access on their own; they must report blockages to the parent Agent. Internal tool permissions for out-of-process Providers like Codex, ACP, and dsh-sdk are not within this plugin’s registry boundary.
Installation and Enabling¶
Before use, ensure that DeepSeek Harness is installed.
Install via npm (Recommended)¶
The installation commands on the SkillHub catalog page and GitHub README are consistent:
dsh plugin --profile web add @nanmicoder/dsh-auto-mode
If you are actually using a different Profile, replace web with the corresponding name.
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 .
After modifying the source code, you need to run pnpm build again; local installation will maintain a link to the current checkout.
Verify Configuration and Launch¶
dsh --profile web --dump-config
dsh web
Refresh the Web UI, select Auto-approval between “writable workspace” and “full access,” read and confirm the risk warnings, and then you can use it.
Typical Usage Examples¶
Daily Development: Auto Flow Under Auto Mode¶
In Auto mode, the Agent typically does not require repeated approval clicks for the following operations:
- Running
pnpm install,npm test,cargo build, etc., within the project directory; - Using the official string replacement editor to modify source code;
- Cleaning up temporary files created within the current Session.
The following temporary runners will still be reviewed (as they download and execute packages not included in the project dependencies):
npx,bunx,pnpm dlx,yarn dlx,npm exec
Optional: Fix Model Routing for the Classifier¶
By default, Auto uses the current Session’s DSH Provider and model, requiring no additional API Keys. If you wish to fix a dedicated classification route in a trusted Profile, you can write the following in the plugin configuration:
- id: auto-permission-mode
config:
classifierProvider: deepseek-official
classifierModel: deepseek-v4-flash
classifierTimeoutMs: 30000
classifierMaxOutputTokens: 1024
For the complete decision order, threat model, and Windows path handling, see the repository’s DESIGN.md.
Applicable Scenarios and Notes¶
Who is it suitable for:
- Those who use DSH Web UI daily for project development and want to reduce approval interruptions during “installing dependencies / running tests / modifying code”;
- Those needing a more secure middle layer than Full access yet smoother than pure Workspace Write;
- Teams interested in admin-security plugins who are willing to read the source code before installation.
Important boundaries to be aware of:
- The plugin runs with the current dsh process’s permissions. Before installation, please read the GitHub repository source code and MIT license to confirm it meets your security requirements.
- The file sandbox does not restrict reads, network access, or external services; the Windows ACL backend has documented
partialenforcement boundaries. Auto is a semantic layer supplement, not a universal firewall. - The plugin cannot intercept package lifecycle scripts executed before loading, direct Node calls bypassing
ctx.tools, compromised Harness Runtime, or commands launched outside the Harness. - Full access remains a user-explicitly-chosen sandbox-free, approval-free mode; this plugin cannot make it safe. The design goal is to keep the vast majority of tasks within the sandbox, only borrowing minimal privilege once when business necessity requires.
- The tested version is DSH 0.1.0-rc.6; after upgrading the Harness major version, it is recommended to re-verify the plugin’s behavior.
Conclusion¶
If you are running a Coding Agent on DSH long-term and find yourself oscillating between “frequent approval clicks” and “complete permission release,” dsh-auto-mode is worth a try: it embeds Auto mode back into the official sandbox, uses a classifier to cover semantic risks beyond the sandbox, and uses hard rules to protect system and credential boundaries.
- Plugin catalog page: https://www.skillhub.cn/plugins/NanmiCoder/dsh-auto-mode
- GitHub repository: https://github.com/NanmiCoder/dsh-auto-mode
- npm package: https://www.npmjs.com/package/@nanmicoder/dsh-auto-mode