Introduction

DeepSeek Harness (DSH) provides four permission modes: Read-only / Workspace / Write / Full Access, but the logic for “whether to prompt the user” supports only two levels: ask / never. This is often too coarse for fine-grained risk handling, causing developers to repeatedly click confirm in high-frequency, low-risk operations.

The dsh-auto-approval plugin adds a fifth mode to DSH: Guardian mode. It introduces an LLM subagent that, before a prompt is triggered, assesses risk and verifies local state. Low-risk operations are allowed through directly, while uncertain operations are asked about as usual.

Core Features

LLM Risk Assessment and Session Analysis

The plugin imitates Codex’s “Approve for me” mechanism. The arbiter reads the session history and injects it as “untrusted evidence” to determine whether the user actually authorized the current operation.

Local State Validation

Before making a judgment, the arbiter can call three read-only tools to verify the local filesystem:
* read_file: read file contents
* list_dir: list directory entries
* stat_path: check path status

This resolves logical judgment issues such as “whether the user actually authorized deleting a non-existent file.”

Four-Field Arbitration Mechanism

The arbiter output includes conclusions across four dimensions:
* risk_level: risk level
* user_authorization: level of user authorization
* outcome: allow or block
* rationale: reasoning for the decision

Only operations explicitly judged safe are executed silently.

Installation and Enablement

Installation

After downloading the corresponding .tgz file, run:

dsh plugin --profile web add dsh-auto-approval-<version>.tgz

Enable and Configure

After installation, restart DSH. There are two ways to enable it:
1. UI operation: in the tool list of the input box, locate the Auto pill next to the permission mode switch and click to turn it on.
2. Configuration file: configure the auto-approval namespace in settings.yaml, or configure it via the “Settings -> Auto Approval” panel. To disable it by default, set enabled: false in the configuration.

Technical Details and Notes

Fail-Closed Design

This is the security foundation of the plugin. If the arbiter encounters an error, times out (default 90 seconds), returns unparseable content, or exhausts its steps, the system automatically falls back to a manual prompt.

Model Requirements

The model used as the arbiter must support Function Calling. If the model does not support tool calls, the plugin degrades to simple text-based judgment.

UI Experience

The interface provides no feedback during judgment, and in the worst case there may be a 90-second timeout delay. This is a design trade-off, not a hang.

Scope

The plugin applies to the entire process and takes effect for all sessions, including subagents.

Security Boundary

Because the arbiter tools can read absolute paths, do not enable this feature on shared machines unless you fully trust the local filesystem security policy.