dsh-auto-approval-plugin

1. 安装并启动 DeepSeek Harness：npx @deepseek-ai/dsh web
2. 在终端执行上面的安装命令（CLI 会解析插件并核验来源）
3. 用 dsh plugins list 确认已安装，必要时重启 Harness 生效

插件以当前 dsh 进程的权限运行，安装时可能执行代码。请先通读仓库源码与许可证，确认无破坏性命令与越权访问；本站只做索引，不对第三方插件安全性作担保。

事实信息来自公开插件目录快照（2026-10-01），介绍文案由本站再加工。

以下为插件仓库 README 全文（原始内容，由公开目录抓取整理）。

# dsh-auto-approval-plugin

> 🌐 **Language**: English | [简体中文](README.zh.md)

A middle permission tier for [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness), between **Workspace Write** and **Full access** (danger-full-access): it adds a `auto-approval` preset to the permission settings and backs it with an automated approval answerer that approves **harmless commands** and operations whose target lies inside **configured trusted areas** — including areas outside the current workspace — and asks the user for everything else.

> ⚠️ **Scope control, not a security boundary.** This plugin automates the *human* approval step for a narrow, verifiable class of requests. The DSH sandbox still confines every non-escalated call; an auto-approved call runs with the wider mode for exactly that one call (the same one-shot grant a human click would produce). Do not use it on machines or sessions you would not trust a human operator to run commands on.

## What it does

| | Workspace Write | **Auto Approval** (this plugin) | Full access |
|---|---|---|---|
| Sandbox mode | `workspace-write` | `workspace-write` | `danger-full-access` |
| Approval policy | `ask` | `ask` | `never` |
| Writes inside workspace / temp | allowed | allowed | allowed |
| Harmless commands (see rule table) | ask | **auto-approved** | never asks |
| Targets inside trusted areas | ask | **auto-approved** | never asks |
| Everything else | ask | ask | never asks |

After installing, the new preset appears in both permission surfaces:

- **General settings → Permission** — sets `auto-approval` as the default for future sessions;
- **`/permission` picker** — switches the current session immediately (`/permission auto-approval`).

## How it works

DSH routes every operation that needs approval through the `approval/request` waterfall ([approval seam](https://github.com/deepseek-ai/deepseek-harness/blob/main/docs/subsystems/approval.md)). This plugin registers a listener with `prepend`, so it runs **before** the web approval prompt:

1. For each request it looks up the recorded `tool/call` event by `callId` in the session log and reads the **real tool arguments** (command text, `file_path`, `workdir`) — it never trusts the model-written justification string.
2. The pure decision core ([`lib/decide.js`](lib/decide.js)) classifies the request as `allow` or `defer`. Path containment is evaluated on **real identity**: the deepest existing ancestor of every candidate path is resolved through `realpath` (the same mechanism the DSH filesystem sandbox uses), so symlinks and junctions cannot smuggle an auto-approval to a target outside a trusted area.
3. `allow` returns `allowed-once` — the request never reaches the human UI; the audit pair `approval/asked` + `approval/decided: allowed-once` is still written to the session log, and the plugin logs the matched rule.
4. `defer` calls `next()` — the deployment's human answerer decides as usual. **The plugin never denies anything.**

## Install

```bash
# from the npm registry
dsh plugin --profile  add dsh-auto-approval-plugin
# or from GitHub (pin a commit for reproducibility)
dsh plugin --profile  add github:StyxNether/dsh-auto-approval-plugin#
```

The bundle patch restates the complete permission preset table (DSH patches replace a row's whole config), so keep it in sync with `@deepseek-ai/dsh-base`'s table when upgrading DSH — the patch warns and is skipped if the target row is missing.

## Configure

Two layers, both live (no restart needed):

1. **Web settings page** (easiest): Settings → **Auto Approval** (a dedicated page in the settings sidebar, like the Vision Toolkit page). Edit trusted areas (one absolute path per line), the harmless/dangerous pattern tables, and the switches there. Changes are written to the `auto-approval` section of `settings.yaml` and apply immediately. The page also shows the last few auto-approval decisions.
2. **Composition config** (the default base): set in your profile's `cordis.patch.yml`:

```yaml
# ~/.dsh/profiles//cordis.patch.yml
- id: auto-approval
  config:
    # Absolute paths treated as trusted areas. Commands whose workdir lies
    # inside one (and reference it), and fs write/edit targets inside one,
    # are auto-approved. Empty by default: the feature is inert until you
    # add areas.
    trustedAreas:
      - 'D:\data'
      - 'E:\repos'
    # Only sessions whose effective preset is `auto-approval` auto-approve.
    requireTrustedPreset: true
    # Regex sources matched (case-insensitive) against command text.
    harmlessPatterns: [ ... ]   # defaults: see lib/decide.js
    dangerousPatterns: [ ... ]  # a match defers to the human, never denies
    maxCommandChars: 4000
    logDecisions: true
    # Non-loopback hosts allowed to reach the configuration HTTP API
    # (loopback is always allowed; cross-site requests are rejected).
    trustedHosts: []
```

Settings values overlay the composition defaults; the web card marks fields you have overridden and offers a one-click reset back to the defaults.

## What is auto-approved (rule table)

For `pwsh` / `bash` calls:

| Rule | Condition | Example |
|---|---|---|
| `harmless-command` | Pure introspection, no shell metacharacters (`; & \| < > \` ` $( newline`) | `ls -la`, `Get-Process`, `whoami`, `echo hello` |
| `harmless-repo-command` | git/hub read command **and** workdir inside a trusted area | `git status`, `git branch` in `D:\repos\app` |
| `trusted-area-command` | workdir inside a trusted area **and** the command references a trusted path | `Copy-Item D:\data\a D:\data\b` with workdir `D:\data` |

For `write` / `edit` (fs) calls:

| Rule | Condition | Example |
|---|---|---|
| `trusted-area-target` | `file_path` (absolute, or relative resolved against the session cwd / workdir) lies inside a trusted area | `write` to `D:\data\out.txt` |

Everything else — including `git pull`/`push`/`fetch`/`checkout`, `git diff`/`log -p` (they can run repo-configured textconv/pager programs), commands with redirection or pipes, writes outside trusted areas, and every other tool — **defers to the user**.

### Deliberately never auto-approved

- Shell metacharacter commands (redirects, pipes, chaining, substitution) — the "harmless" window accepts only a single simple command.
- git operations that write, fetch or merge, and `git diff`/`git log -p` — untrusted repositories can weaponize git via `.git/config` (textconv, fsmonitor, pager), so git auto-approval requires a trusted workdir and stays on the read-only family.
- Anything matching `dangerousPatterns` (drive/system-root wipes, `rm -rf /`, `format`, `diskpart`, `shutdown`, fs targets inside `Windows` / `Program Files`, …) — these defer to the human even inside trusted areas.
- Requests whose `tool/call` cannot be found in the session log, or whose arguments are missing or oversized — no data, no auto-approval.

## Security

- **No secrets.** The plugin contains no API keys, no network access beyond its own same-origin config API, and no `eval`/dynamic code. It never reads configuration outside its own config and settings section.
- **Auditable.** Every auto-approval is a one-shot grant recorded in the session log (`approval/asked` + `approval/decided`) plus a logger line naming the matched rule; the settings card shows the most recent decisions.
- **Fail-safe direction.** Errors in the decision path log a warning and delegate; the plugin cannot deny, block, or lock out a session.
- **Gated config API.** `GET/PUT /api/dsh-auto-approval-plugin/config` accepts only loopback (or configured `trustedHosts`) same-origin requests; cross-site fetches are rejected. It reads and writes only the plugin's own settings namespace.
- See [SECURITY.md](SECURITY.md) for the threat model and reporting.

## Uninstall (no residue)

1. Remove the plugin: `dsh plugin --profile  remove dsh-auto-approval-plugin`
2. Remove the trusted-area override from your profile's `cordis.patch.yml` (the `- id: auto-approval` entry, if you added one).
3. Remove the `auto-approval:` section from `settings.yaml` (written by the web card, if you saved there).
4. Verify no residue: `dsh --profile  --dump-config` should contain no `auto-approval` row; `grep -n "auto-approval" ~/.dsh/settings.yaml` should find nothing.

Nothing else is touched: no other files, no sessions, no credentials.

## Development

```bash
npm test          # node:test unit tests for the decision core
npm run check     # syntax check + tests
```

The decision core is dependency-free plain JavaScript; the plugin surface is a standard Cordis plugin (see `lib/index.js`).

## License

MIT — see [LICENSE](LICENSE).