dsh-allow
DeepSeek Harness 权限记忆插件：将某类命令加入允许列表，之后相同命令不再询问。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:DWJZ/dsh-allow#9e852119e6d1e483f4c780fcd0a4c7a1eb18d17c记住 sandbox-escalation 审批，以便相同命令不再询问。
Allow 以 dsh-allow 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
English | 中文
The permission card grows a third button — 总是允许「pnpm dsh plugin」开头的命令 — and the rules it writes live in your harness home, managed with /allow. Click it and the command continues; the same command prefix never asks again.
DSH keeps a file sandbox: a command that writes outside the session workspace is denied, and the model may retry it with sandbox_permissions, which raises an approval card. That card is fine the first time and tedious the tenth, because the same handful of operations keep coming back (pnpm dsh plugin …, brew install …, gh repo view …).
拒绝 — deny the call.总是允许「gh repo view」开头的命令 — store that rule, then allow this call.允许一次 — allow this call only.write/edit path escalations, anything that is not a sandbox escalation) keeps the built-in card untouched.A rule is scoped by tool + requested sandbox mode + the command's leading words, and it only ever covers a single command (see below), so allowing pnpm dsh plugin never allows rm, and a rule recorded for danger-full-access does not cover a different request. The prefix drops a leading cd … &&, drops VAR=value, reduces the program to its basename (/opt/homebrew/bin/gh → gh), and then keeps words until the first flag, path, or shell operator. The button names the exact prefix before you agree to it.
A compound line never rides a rule. brew install gh && rm -rf / starts with the words a rule for brew install gh names, but the rule grants the whole line — so the second half would ride along. Such a line is therefore never matched against rules and never offers the always-allow button: the card says why and asks every time. A leading cd … && chain is the one exception, because the rule names the program after it (cd /tmp && brew install gh is rememberable as brew install gh). Pipes, semicolons, redirects, $(…), backticks, and multi-line commands all count as compound.
Paths are not part of a rule. A rule names a command, not a directory. Path scoping is the sandbox's job: under workspace-write the session workspace plus the platform temp areas are writable with no prompt at all, and everything outside them is denied — which is where this card appears. So "let me write under ~ but ask for /" is expressed by making the session workspace ~ (add it as a workspace and start the session there), not by a rule. Rules then only decide which programs may reach outside that boundary.
# from GitHub
dsh plugin --profile web add github:DWJZ/dsh-allow
# local development
dsh plugin --profile web add link:/path/to/dsh-allow
/allow/allow # same as /allow list
/allow add bash danger-full-access pnpm dsh plugin
/allow remove 2
/allow clear
$DSH_HOME/dsh-allow.json (override with the rulesFile config field):
{
"version": 1,
"rules": [
{ "id": "r1758000000000", "hits": 4, "tool": "bash", "mode": "danger-full-access", "prefix": "pnpm dsh plugin" }
]
}
Unreadable or hand-edited files degrade to "no rules" rather than blocking approvals; deleting a rule just means the card asks again.
The built-in approval card's action row is fixed (拒绝 / 允许一次), and its only slot is the command detail — a plugin cannot add a button to that component. This plugin therefore registers its own conversation.composer chain entry at a lower priority than the built-in one, and renders a card with the same markup and the same CSS declarations, plus the extra button. It matches only sandbox escalations, so every other approval still renders through the built-in card.
The two host routes behind it:
GET /dsh-allow/pending?sessionId=…&callId=… — what this approval would remember (prefix + command), so the button can name it. Loopback only.POST /dsh-allow/remember — store the rule. Same-origin loopback only.npm test # host suite + browser suite
The host suite covers prefix derivation, the escalation shape, rule storage and matching, the pending store's identity and expiry rules, both routes (including their refusals), and the /allow grammar. The browser suite loads the client bundle, checks the chain registration and its escalation predicate, and server-renders the card. Set DSH_CHECKOUT=<dsh checkout> for the render assertion.
write/edit path escalations keep the built-in card.