Introduction

To let agents run tasks continuously, there are usually only two options regarding permissions: either use conservative presets where every write operation stops and waits for confirmation; or switch directly to danger-full-access. The speed is faster, but the agent does whatever it wants, and there is no gate to stop it if things go wrong. DeepSeek Harness’s (DSH) permission presets—read-only, workspace-write, and danger-full-access—are all at these two ends, missing a middle tier that is “loose but has someone blocking dangerous actions.”

The dsh-automode introduced below fills this gap: it is a DSH plugin that provides a Claude Code-style auto mode, allowing the agent to run without manual intervention, with deterministic guardrails and a cost-aware reviewer blocking dangerous operations.

What is this

dsh-automode (npm package @log.li/dsh-automode) is a DSH plugin maintained by GitHub user log-li, under the MIT license. One-sentence positioning: Claude Code-style auto mode for DeepSeek Harness—agents run without manual intervention, with deterministic guardrails and a cost-aware reviewer intercepting dangerous operations.

It plugs between the agent and the harness: every tool call is intercepted before execution. Hard deny rules and manually maintained allowPaths deterministically allow or reject, with zero LLM overhead; the rest is handled by a two-stage classifier. Safe actions run themselves, while risky ones are blocked or escalated to humans.

Installation and Usage

First, install the plugin:

dsh plugin add @log.li/dsh-automode

When debugging via local checkout, you can point to a local path:

dsh plugin add ./path/to/dsh-automode

After installation, you need to restart dsh web. After restarting, open the permission selector (bottom left of the chat box), and you will see Auto mode alongside read-only, workspace-write, and danger-full-access.

There are two commands available within a session:

/auto           # Switch current session to auto mode
/auto-status    # Display diagnostic info: preset, approval policy, circuit breaker status

How it Works

It is divided into two layers overall: the pre-execute gate intercepts all tool calls for the first round of sorting, and calls requiring sandbox upgrades go through an approval waterfall, where the classifier decides. Below, I break them down in order.

Pre-execute Gate: The First Gate for All Calls

The pre-execute gate intercepts all tool calls and processes them in a fixed order:

  1. Read-only tools are allowed by default (except when they hit a deny rule);
  2. If a deny rule (regex) is hit, it is hard-blocked;
  3. allow rules (prefix-glob) bypass the LLM for approval;
  4. File operations within the working directory are allowed;
  5. The rest of the calls are routed based on whether they require sandbox upgrades.

Two points to note: The pre-execute gate only works on auto-mode sessions; it is a no-op under other presets like read-only, workspace-write, and danger-full-access, and will not conflict with your selected sandbox. The approval waterfall only runs for calls that truly require sandbox upgrades; other calls do not incur this overhead.

Zero-Confirmation Allowlist

config.allowPaths is a fully trusted zone: file operations and bash write commands within it completely bypass the classifier. Starting from v0.10.0, calls requiring sandbox upgrades are also automatically granted via the approval-bridge—no confirmation popup, no round trips. It is suitable for adding frequently used external working directories to save on high-frequency confirmations.

Two-Stage Classifier

Actions entering the waterfall first pass a single-token pre-filter; only those marked proceed to structured review. Determinations for the same action are cached and reused within 5 minutes, avoiding repeated LLM calls. Starting from 0.8.0, the classifier is binary, outputting only allow or reject.

By default, when the classifier fails, it is fail-closed (failClosed defaults to true): it is better to reject than to allow.

Circuit Breaker and Human Fallback

If the classifier outputs DENY 3 times in a row or accumulates 20 times, auto mode pauses, and decision-making reverts to a human. Once a human makes a decision, it resumes, and the counter resets. This mechanism ensures that when problems occur, it stops and hands control back to a human rather than silently drifting off track.

Audit Log

Every allow/deny/bridge decision is appended to ~/.dsh/auto-mode/decisions.jsonl. Through the steps above, a tool call is either allowed or hard-blocked by deterministic rules, or decided by the classifier. Everything is logged, allowing for complete retrospective analysis afterward.

Rule System: Hard Boundaries and Soft Guidance

Rules are divided into two layers.

The first layer is the hard boundary, executed deterministically without entering the classifier:

  • deny: regex pattern, hard-blocked on hit, suitable for operations that must never happen;
  • allow: prefix-glob pattern, bypasses the LLM for approval, suitable for trusted regular commands.

The second layer is classifier guidance, provided to the LLM classifier in prose form:

  • rules.deny: soft rejection description, treated by the classifier as a normal rejection;
  • rules.allow: soft allowance exceptions;
  • rules.environment: environmental facts, for the classifier to use in conjunction with context to make decisions.

All three rules.* arrays support $defaults: including "$defaults" in the list preserves built-in rules and appends your custom items.

Configuration

Configuration is written in the profile’s cordis.patch.yml. All configuration items have default values, and an empty {} configuration is also valid. Common items:

  • allowPaths: directory list for the zero-confirmation allowlist;
  • readOnlyTools: collection of read-only tools allowed by default;
  • allowInsideWorkingDirectory: whether file operations inside the working directory bypass the classifier;
  • preExecuteGate: toggle for the pre-execute gate (only applies to auto-mode sessions);
  • classifier.provider / classifier.model: override the LLM routing for the classifier;
  • classifier.reasoningLevel: reasoning level for the classifier, default off;
  • rules.deny / rules.allow / rules.environment: soft rejection, soft allowance, and environmental fact guidance for the classifier;
  • failClosed: defaults to true, rejects when the classifier fails;
  • timeoutMs: upper limit for call timeout, default 45000 milliseconds.

Use Cases and Considerations

Suitable for: DSH users who want agents to run tasks without confirmation for long periods but do not trust enabling danger-full-access directly. Hard rules block clearly dangerous operations, allowPaths skips confirmations for high-frequency trusted operations, the classifier covers the remaining uncertain actions, and the circuit breaker ensures stopping and handing control back to humans when problems occur.

Before using, a few points must be clear:

  1. This is not a sandbox. The plugin runs inside the DSH process and works with the permissions of the current dsh process. A deliberately malicious plugin can do everything your user account can. dsh-automode reduces unsafe autonomous tool calls; it is not an OS security boundary.

  2. Before installing any third-party plugin, it is recommended to read the source code and verify the license. dsh-automode uses the MIT license; the repository address is at the end of the article.

  3. DSH’s philosophy is “everything is a plugin”; the plugin directory mentioned in this article is an independently maintained site by the community and has no official affiliation with DeepSeek or Magic.

Summary

dsh-automode changes the binary choice of “whether to let the agent run” into an adjustable gradient: deterministic rules handle deterministic matters, cost-aware classifiers handle uncertain matters, with circuit breakers and audit logs as a fallback. For those who want to run auto mode on DSH, you can start from these two places: