simon300000/dsh-auto

dsh-auto

English | 中文

dsh-auto adds an Auto Approve permission preset to the DeepSeek Harness Web UI. Each action that requires approval is reviewed by a fresh, restricted DSH child Agent before the plugin allows or denies it.

The current release supports the Web UI only.

Screenshots

Select the 🧐 Auto Approve permission preset (DSH 0.1.5-rc.1, English UI):

The Reviewer allows a bounded read-only action:

The Reviewer denies a high-risk action without sufficient user authorization:

How it works

flowchart TD
    action["Action"] --> sandbox{"Allowed by<br/>workspace-write?"}
    sandbox -- Yes --> execute["Execute directly"]
    sandbox -- "No: request escalation" --> review["🧐 Auto Approve"]
    review -- Allow --> approved["Execute this action once"]
    review -- Deny --> rejected["Reject the action"]

With Auto Approve selected, ordinary actions permitted by workspace-write run without a Reviewer call. The diagram shows the sandbox-escalation path; other tool approval rules can also trigger Auto Approve.

• The plugin handles approval/request only when the session selects Auto Approve. Other permission presets continue through DSH's existing approval chain.
• Each approval starts one spawn Reviewer session. DSH's own agent loop handles any bounded read, glob, or grep investigation and captures the final structured result; the plugin does not implement a separate model/tool loop.
• The child is created with a read-only sandbox and approval/policy = never. An execution guard denies every tool except read, glob, grep, and the scoped structured-output tool, permits no further subagents, and allows at most four investigation steps plus the final response step. Sensitive files may be inspected only when a minimal read-only check can change the decision.
• The Reviewer receives the exact pending action, approval reason, current permissions, bounded raw session events, the main Agent's assembled system instructions, and AGENTS.md or equivalent workspace instructions. Stable instructions are serialized in a separate cacheable prefix before session identifiers, transcripts, permissions, and action data. Direct user messages, human answers returned by ask_user_question, assembled system instructions, and workspace instructions can establish authorization; assistant content and other tool results remain untrusted evidence.
• Only outcome is required in the structured result. A compact {"outcome":"allow"} defaults to low risk and unknown authorization; omitted fields on a denial default to high risk and unknown authorization. Explicit assessments may also contain risk_level, user_authorization, and rationale. The host always denies critical risk and denies high risk without at least medium user authorization. Invalid output, missing action data, timeout, cancellation-independent infrastructure failure, and tool failure all fail closed.
• A successful model denial is not retried and never falls back to a user prompt. The default 90-second deadline covers child creation, all model steps, local read-only investigation, and final structured output.
• Three consecutive denials in the same parent turn interrupt that turn. Any allowed action resets the counter. Each approval is still isolated in its own child session.