feat(execpolicy): add typed persistent permission rules

[greyfreedom]

Summary

Add typed persistent permission rules to the execution policy/config layer.

The first version should support rules scoped by:

• tool name
• command prefix
• workspace-relative path pattern
• decision: allow, deny, or ask

This should extend the existing execpolicy ruleset model instead of introducing a separate permission engine.

Motivation

DeepSeek-TUI already has shell command approval rules through auto_allow / deny prefixes, layered rulesets, and bash arity-aware command matching.

However, the current model is still mostly shell-command focused. Repeated tool workflows would benefit from a typed permission rule schema that can represent decisions such as:

[[permissions.rules]]
tool = "exec_shell"
decision = "allow"
command = "cargo test"

[[permissions.rules]]
tool = "exec_shell"
decision = "deny"
command = "rm -rf"

[[permissions.rules]]
tool = "file_edit"
decision = "ask"
path = "src/**"

This provides a foundation for future UI support such as “always allow this pattern” while keeping the first implementation focused on policy/config behavior.

Proposed Behavior

• Add a typed permission rule type with:
  • tool
  • decision
  • optional command
  • optional path
• Support decisions:
  • allow
  • deny
  • ask
• Keep existing auto_allow / auto_deny behavior compatible by mapping them to exec_shell rules.
• Reuse the existing bash arity logic for shell command matching.
• Support workspace-relative glob-style matching for file paths.
• Preserve deny-wins behavior.
• Treat ask as an explicit rule that forces approval even when the broader policy would otherwise allow execution.

Non-goals

• No TUI approval modal changes in the first PR.
• No “always allow this pattern” persistence UI yet.
• No complex permission DSL.
• No regex or boolean expressions.
• No full MCP permission coverage yet.

Acceptance Criteria

• execpolicy exposes typed permission rules.
• Config can deserialize [[permissions.rules]].
• Legacy auto_allow / auto_deny still work.
• deny > ask > allow precedence is covered by tests.
• Shell command rules continue to use bash arity matching.
• File path rules support workspace-relative glob matching.
• Tests cover config parsing, legacy compatibility, precedence, and path matching.

Implementation Plan

• PR 1: execpolicy + config typed permission rules — feat(execpolicy): add typed permission rules and config schema #2046
• PR 2: apply typed rules to shell/file tool execution — feat(tui): route shell and file tool approvals through typed execpolicy rules #2053
• PR 3: TUI approval UI for persisting rules — feat(tui): persist permission rules from approval prompts #2062

[Hmbown]

thank you so much - very helpful with the PRs!!!! this is going in 0.8.22

[greyfreedom]

Hi @Hmbown , I’ve finished implementing the changes for this issue and split them into several PRs for easier review.
Each PR is intended to be reviewed independently but may depend on the previous one. Please let me know if any part should be adjusted.
Thanks!