940842546/dsh-permissions
Claude Code-style permission rules engine: hard/deny/ask/allow tiers with a hard tier above full access, workspace-scoped rules, wildcard path protection, and a visual staged editor; rules persist in settings.yaml.
dsh-permissions is a Claude Code-style permission rules engine for DeepSeek Harness. It adds a host engine on the tools/pre-execute waterfall plus a visual editor in Settings -> Permissions, with four rule tiers and strict precedence (hard > deny > ask > allow). hard rules outrank full access (they keep blocking even on the full-access preset with approval policy never), while ask rules follow the session policy and auto-pass under full access. Rules are scoped global or per-workspace (merged on top, deny winning conflicts) and support wildcard matching for file tools (write(*.pem), write(secret), write(.ssh), write(C:\users\*), or a bare write for every invocation). Active rules are injected into the system prompt under [active-permission-rules] for model transparency, and the visual editor uses staged (draft) editing that applies only on Save & Apply, with one-click presets (protect sensitive dirs / key files / dangerous commands).
Install
dsh plugin add dsh-permissionsRun dsh plugin add dsh-permissions. Option B is a manual patch row: install the package where the profile resolves it (~/.dsh/node_modules/dsh-permissions) and append the insert list from the repo's cordis.patch.yml (a permissions row with name dsh-permissions) to ~/.dsh/cordis.patch.yml or ~/.dsh/profiles/<profile>/cordis.patch.yml, then restart the app. The npm package dsh-permissions was re-verified live on the registry on 2026-09-30 (2.0.2) with a description matching this plugin (the Chinese description names the hard/deny/ask/allow four-tier rules engine), but the registry entry exposes no repository field, so the back-link cannot be confirmed from the registry alone. The Settings -> Permissions page appears automatically and the engine starts with safe defaults (16 hard rules protecting .ssh / .aws / .gnupg / AppData / .pem / .key / .env / .htpasswd, plus deny: pwsh(rm -rf *)).
Compatibility
DeepSeek Harness (dsh), installed as a dual-face Cordis plugin: a host engine on the tools/pre-execute waterfall plus a browser-side visual editor. Rules live in the dsh-permissions settings namespace and survive restarts (<harness home>/settings.yaml). The settings route (GET/POST /api/dperm/rules) is the namespace owner's own endpoint because the DSH api-proxy's settings allowlist intentionally does not expose third-party namespaces. Restart the app after installing so the patch row takes effect. The engine only narrows the session's existing sandbox/approval posture -- allow skips this plugin's own ask but never bypasses the DSH sandbox or tools.guard guards.
Details
- Repo: 940842546/dsh-permissions
- Category: Workflow & Automation
- Stars: 0
- Version: npm dsh-permissions 2.0.2 (registry re-verified 2026-09-30; description matches but no repository field is published); MIT
- Last push: 2026-08-19
- First seen: 2026-08-15
Recent updates
The README documents the rule-syntax table, the installation options, the Permissions page behaviour (engine toggle, three preset cards, a point-and-click rule builder, four coloured rule panels, staged saving), the security notes (the engine only narrows the existing posture; denials surface to the model as a permission-rule error so the agent can route around blocked calls; the settings route is the namespace owner's own endpoint), and points to PUBLISH.md for the release checklist and pitfalls.
FAQ
- How do I install dsh-permissions?
- Per the README's Option A, run dsh plugin add dsh-permissions (or add the permissions insert row from the repo's cordis.patch.yml manually), then restart the app; the Settings -> Permissions page appears automatically. The npm package was re-verified on 2026-09-30 at 2.0.2.
- Do hard rules override full access?
- Yes -- the README states hard rules keep blocking even when the session is on the full-access preset (approval policy never), placing the hard tier above deny, ask, and allow.
- Does an allow rule bypass the sandbox?
- No -- the README says the engine only narrows the session's existing sandbox/approval posture; allow skips this plugin's own ask but never bypasses the DSH sandbox or tools.guard guards.
Alternatives
bigclawd/dsh-security-guard · DamonKoy/dsh-projection-guard · good-boy4069/dsh-vision-guard