Preface¶

DeepSeek Harness (referred to as DSH for short) is an open-source coding agent runtime from DeepSeek, whose official repository positions itself as “Everything is a Plugin” — permission presets, sandboxes, approvals, and tool chains can all be composed via plugins. The default permission profiles provided by the official repository are relatively strict: the workspace-write profile blocks writes outside the workspace, but many daily operations still require repeated approval clicks; the danger-full-access profile cancels approval requirements entirely. There is a gap between these two options: a middle ground that allows daily work to proceed smoothly while blocking dangerous actions.

dsh-auto-mode fills this gap. It inserts a permission preset named Auto between Workspace Write and Full access: ordinary project operations continue to use the official workspace-write file sandbox; semantic risks not covered by the sandbox are classified by the DSH model of the current session; truly ambiguous actions only require one confirmation; and destructive actions targeting critical paths such as the root directory, Home, and DSH_HOME are directly rejected before execution.

This article is collated after cross-verifying against the community plugin directory page, GitHub repository README / DESIGN.md, and npm package documentation. The community directory deepseek-harness-plugin.com is an independent site and has no official affiliation with DeepSeek / HyperGAN, so please do not treat it as an official app store.

What is this¶

dsh-auto-mode is a workflow and automation DSH plugin. Its GitHub repository is maintained by NanmiCoder, with the npm package name @nanmicoder/dsh-auto-mode. The current version is **0.1.4**, licensed under MIT. The author field inpackage.json` lists developer Ajiang (Relakkes). The primary language of the repository is TypeScript. As of the writing of this article (2026-08-17), querying the GitHub API shows 74 stars; the community directory page showed 36 stars at that time, so please refer to the repository’s own data for star counts.

The problem it solves can be summarized in one sentence: add an Auto permission preset permanently attached to the official workspace-write sandbox, using deterministic rules and a semantic classifier to reduce approval interruptions, while avoiding directly enabling Full access.

DESIGN.md clearly states that this plugin **does not implement its own sandbox, nor does it provide its own executor. It only does three things:
1. Insert the Auto preset into the official permission preset list;
2. Attach a Host policy layer onto the official ctx.tools pipeline;
3. Add the Auto icon and risk confirmation pop-up to the tested DSH Web UI.

The implementation targets the official DeepSeek Harness checkout 47f943859bef60e4160492346772ded9b24f765a, with build and test aligned with the publicly available0.1.0-rc.6package. Relevant upstream interfaces include@deepseek-ai/dsh-permission-presets,@deepseek-ai/dsh-sandbox-policy,ctx.tools.guard(), theallowed-onceinctx.approval, andctx.llm.stream()` as an independent semantic reviewer.

How the permission modes are ordered¶

After installation, four modes will appear in the permission selector. Auto and Workspace Write share the same file boundary but behave differently:

Ordinary Auto work still stays within the Workspace Write boundary. Only explicit one-time cross-boundary requests may be automatically approved. The official file sandbox restricts where writes occur, not reads, network access, or external services; on Linux it uses bwrap/Landlock, on macOS it uses Seatbelt, and on Windows the restricted token / ACL backend reports a partial execution.

Core decision-making¶

The README divides Auto’s decision-making into four categories, consistent with the decision order in DESIGN.md.

Auto-allowed. Sandboxed unfamiliar Bash/PowerShell, regular dependency installation (npm, pnpm, yarn, bun, pip, local Cargo), local Git commits, project reads/writes, builds, tests, type checks, and already audited DSH collaboration tools run directly by default. The plugin no longer tries to prove that every Shell syntax via a whitelist: unknown literal commands, parameter variables, pipes, redirections, inline code, and PowerShell combinations default to entering the official `workspace-write sandbox. Writes outside the workspace are rejected by the operating system, and no pop-up will appear just because the static analyzer “does not recognize the command. Only when the executable file name is hidden by variables or globs will it be rejected in the background, requiring the Agent to rewrite it into a visible command.

Background classification. The following actions are handed over to the classifier: deletion of existing data before the start of the session, temporary downloaded package execution (npx, bunx, pnpm dlx, yarn dlx, npm exec), dangerous remote Git/database/service changes, sensitive reads, network transmissions, external system writes, and precise sandbox cross-boundary operations. The classifier is not an authorization source. It only receives execution call descriptions that have been desensitized and length-limited, and can only recognize authorizations from **direct user session messages only. Repository text, tool outputs, Assistants, Skills, plugins, and sub-agents cannot grant permissions.

Ask once. When the effect or authorization is truly unclear, proceed with the official approval process. If the classifier fails three consecutive times, it will also switch to manual confirmation. Cross-boundary operations reuse the official one-time precise approval without triggering double pop-ups.

Direct rejection. Operations targeting the root directory, Home, DSH_HOME, system destruction, permission bypassing, credential exfiltration, hidden dynamic deletions, and two consecutive classifier failures for risky operations will all be rejected before execution. These hard rejections are monotonic: subsequent listeners or classifiers cannot change them to allow them.

Deletion has stricter restrictions than ordinary writes. A single precise product created during the current session whose file identity (device number, inode, birth time, type) has not changed can be automatically cleaned up; a single existing file or directory is only classified for deletion only when the direct user message precisely requests deletion of that target; a single existing target outside the workspace will be granted one-time cross-boundary authorization after precise authorization; multi-target, glob, variables, pipe input, nested interpreter deletions will be rejected in the background, requiring the Agent to split them into one visible literal target at a time. Once a path is renamed, replaced, replaced with a symbolic link, or old files are mixed into a new directory, it will no longer qualify for automatic cleanup. When the user has not explicitly requested permanent deletion, the Agent’s guidance will prioritize moving, backing up, or using version control for deletion.

When a task explicitly requires writing outside the workspace, the Agent can retry using the official sandbox_permissions: danger-full-access with a justification. For new, small-scoped, recoverable precise targets, the task intent itself can support one-time background authorization, and the user does not need to say “I authorize” again. Overwriting or deleting existing data still requires the direct user message to precisely point out the effect and target. The reviewer will see the pre-execution existedBefore file facts, and can only return one allowed-once for the same Agent, same tool call, same mode, and same justification; this will not change the session’s permanent permissions.

How sub-agents inherit permissions¶

Official in-process subagents, agent() in Workflows, Ralph spawn workers, and AgentTeam members all inherit the Auto and workspace boundaries via the active parentSession chain, but every file and Shell call is still checked individually. Goals continue to run on the current Agent with unchanged permissions.

Sub-agents use approval: never and cannot apply for danger-full-access on their own; they must report cross-boundary requests to the parent Agent. Internal tools of out-of-process providers such as Codex, ACP, dsh-sdk are governed by their respective permission policies and are not within the tool registry boundary of this plugin.

Installation and activation¶

You need to have installed DeepSeek Harness installed before using this plugin. The plugin runs with the permissions of the current dsh process, and may execute code during installation. Please check the source code repository and license before installation.

The installation command given on the community directory page is:

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

For reproducible installations, the directory page requires pinning the commit hash. As of the writing of this article, the latest commit on the main branch is `007c316840717fa4e30cd6fb7fdcbfba026aba2d, which can be written as:

dsh plugin add github:NanmiCoder/dsh-auto-mode#007c316840717fa4e30cd6fb7fdcbfba026aba2d

The GitHub README recommends installing the npm package via Profile, with the current package version 0.1.4:

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

If you are not using the web Profile, replace web in the command with the corresponding name.

You can also build from source and link locally:

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 re-run pnpm build. The local installation will continue to link to the current source directory. package.json requires Node.js ^22.19.0 or >=24.0.0, and the package manager is locked to pnpm 10.33.0.

Activate Auto¶

After installation, first check the combined configuration, then start the Web UI:

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

Refresh the Web UI, select Auto between Workspace Write and Full access, and confirm the risk prompt. The README specifically notes that the Auto icon and risk confirmation pop-up are only compatible enhancements for the tested DSH Web UI, **not a security boundary.

Configure the classifier¶

No additional Endpoint or API Key is required by default. Auto uses the current session’s DSH Provider and model. If you want to fix a dedicated route in a trusted Profile, you can write it according to the repository documentation:

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

The id inserted by the plugin in cordis.patch.yml is auto-permission-mode, and it also supplements the official permission preset list with the auto profile. For the complete decision sequence, threat model, Windows path handling, classifier payload restrictions, and official source code references can be found in DESIGN.md in the repository.

When the classifier is unavailable, times out, has malformed output, or lacks a model route, the first two consecutive failures will reject the risky action and let the Agent retry or revise the plan; the third consecutive failure in the same Auto Session will fall back to one regular manual approval to avoid the task getting stuck in infinite rejection. Successful classifier responses will reset the count; cancelled calls are not counted.

Applicable scenarios and notes¶

This plugin is suitable for users who are already using DSH for daily coding, who want fewer approval prompts but are unwilling to set the Session to Full access permanently. Typical scenarios include: building and testing in the workspace, installing regular dependencies, local Git commits, and having sub-agents / Workflows / AgentTeams inheriting the same workspace boundary.

Please clarify the following boundaries, all from the README and DESIGN.md, not additional extensions:
1. This plugin cannot make Full access secure. The Full access mode explicitly selects danger-full-access with never approval, and already sits on the permission level of no sandbox and no approval required. Auto’s design goal is not to “guess which commands are safe under full permissions, but to keep most tasks retain the permanent sandbox and only lend out the minimal permissions when the business truly needs it.
2. The official file sandbox does not restrict reads, network access, or external services. Sensitive reads, network transmissions, and external side effects still go through semantic review, but the review covers identifiable semantics, not OS-level isolation.
3. The Windows ACL backend has a publicly known Everyone / hard-link partial boundary, and cannot be understood as fully enforced as Linux/macOS.
4. The plugin cannot intercept pre-load execution package lifecycle scripts, Node file system/process calls that bypass ctx.tools, a compromised Harness Runtime, or commands started outside Harness. Installed Host plugins run with the current process’s permissions and are part of the trusted computing base.
5. The sandbox is not transactional. If a command first writes files within the workspace and then encounters a rejected external write, the previous workspace changes will remain.
6. Consecutive classifier failures, incorrect model selection, or vague user wording will change the actual experience. Repository text and justifications written by the Agent itself cannot be used as authorization.

Please read the source code and MIT license before installation. The plugin runs with the permissions of the current dsh process, and may execute code during installation. For reproducible environments, pin the commit hash instead of following main all the time.

Summary¶

dsh-auto-mode fills the gap between the official permission profiles for DeepSeek Harness: Auto permanently uses workspace-write, uses the OS sandbox to block writes outside the workspace, and then uses deterministic rules and a semantic classifier to handle deletions, temporary package execution, network exfiltration, and one-time cross-boundary operations. It does not replace the official sandbox, nor can it provide security guarantees for Full access.

Directory page: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-auto-mode/

GitHub: https://github.com/NanmiCoder/dsh-auto-mode

npm: https://www.npmjs.com/package/@nanmicoder/dsh-auto-mode