Bcy2020/dsh-cc-ecosystem--packages-cc-permissions ↗★ 6
dsh-cc-permissions
Enforce Claude Code permission rules (.claude/settings.json allow/deny/ask, deny>ask>allow) in DSH via a tools/pre-execute gate; CC allow rules auto-answer the approval/request seam (incl. sandbox escalation). Reads CC settings as a read-only source; DSH-side approvals never write back to .claude. 适合需要复用.claude配置,在工具执行前进行严格权限拦截的用户。
Install
npx -p @deepseek-ai/dsh dsh plugin --profile web add github:Bcy2020/dsh-cc-ecosystem#9d8a2db2f0308debdb5ec901ba9bc99944207d25&path:packages/cc-permissionsREADME
Read the full README ↗dsh-cc-permissions
Enforce Claude Code permission rules in DSH.
Reads .claude/settings.json (user ~/.claude, project, and settings.local.json)
through the shared dsh-cc-loader parse layer and folds the rules
deny → ask → allow on every tool call, exactly like Claude Code:
Toolbare deny removes the tool from the model's context (per-agent hide)Tool(spec)scoped rules match commands, paths, domains, params, MCP tools- Bash compound commands are split; wrappers (
timeout,nice,nohup…) and leading env assignments are stripped before matching - Read deny rules also gate Edit/Write tools and Bash file commands
(
cat,head,tail,sed…) askrules route through DSH's approval serviceallowrules answer the approval seam automatically (see below)
Allow = run without asking (approval seam)
In Claude Code an allow rule is the complete gate: the command runs without
any further question. DSH has a second layer below the permission fold — the
file sandbox. When workspace-write denies a file effect and the model retries
with sandbox_permissions, an approval/request is raised for the escalation;
without a bridge, that request would still hit the human answerer even though
the user already allowed the exact command.
dsh-cc-permissions bridges this: an approval/request (permission ask or
sandbox escalation) whose underlying tool call matches a CC allow rule is
answered allowed-once automatically — one-shot, rule-scoped, and read from
the real tool arguments in the session log (tool/call by callId, never
the model-written reason), mirroring the pattern of
dsh-auto-approval-plugin.
Bash(pytest:*)→ the exactpytest …command may run outside the sandbox when escalated (CC semantics restored)- deny/ask rules and unmatched calls always defer to the human answerer; the module only ever auto-grants, never auto-denies
enableAllProjectMcpServers: truealso covers project MCP tools (mcp____, notmcp__plugin_…)
Disable with autoApproveAllowed: false in the plugin config.
Read-only bridge
CC settings.json is a read-only source. DSH-side approvals ("don't ask
again") are stored in DSH's own config and are never written back to
.claude/settings.local.json — CC, Codex and DSH have different permission
semantics, so cross-tool permission sync is intentionally out of scope
(community agents / cc-suite do not sync permissions either).
Install
dsh plugin --profile add dsh-cc-permissions
Config
| Key | Default | Meaning |
|---|---|---|
enabled | true | Master switch |
hideDeniedTools | true | Bare-name deny → per-agent ctx.tools.restrict |
enableDefaultMode | true | defaultMode=dontAsk → approval policy never |
autoApproveAllowed | true | allow rules auto-answer approval/request (incl. sandbox escalation) |
homeDir | `` | Home dir for ~/.claude/settings.json |
projectRootMarkers | ['.git'] | Project root discovery |
License
MIT.