Permission rules model needs fundamental rethink: shell-aware parsing over regex matching

Problem

The current permission/authorization system for CLI tool calls has several practical issues:

1. Rules don't take effect reliably

When Claude prompts "should I allow XYZ?" and the user approves, a rule is added to the permissions file. However, Claude frequently continues to prompt for the same or equivalent commands. This leads to duplicate rules accumulating in the config with no observable effect.

2. Regex on command strings is the wrong abstraction

Shell commands are not flat strings — they have rich structure that regex cannot capture correctly:

• Flag position independence: -n can appear anywhere in a command. A regex that matches cmd -n foo won't match cmd foo -n, yet they're semantically identical.
• Pipes: cmd1 | cmd2 composes two commands with completely different security implications. A regex matching cmd1 says nothing about what cmd2 does with its output.
• Redirections: cmd > file changes a read-only command into a write operation. The same regex matches both cmd and cmd > /etc/passwd.
• Quoting, expansion, subshells: All of these mean the same regex pattern can match commands with fundamentally different security profiles.

The combinatorial space of valid shell commands means regex pattern matching on serialized command strings will always have gaps — it's a different algebra that doesn't respect the structure it's trying to authorize.

3. The design started at the wrong end

Fine-grained per-command rules are the last thing you build, not the first. A more effective progression:

1. Start with roles — broad permission buckets like "read-only operations", "file modifications", "network access", "remote push". These are easy to reason about and cover the common cases.
2. Observe real usage patterns — learn from actual sessions what commands are run and what the meaningful security boundaries are.
3. Refine into fine-grained rules — only after the role model is validated against real usage, add specificity where roles are too coarse.

The current approach skips straight to fine-grained regex rules without a foundational model, which is why it produces rules that don't work in practice.

Suggested direction

• Parse commands the way the shell does. Use a specific, known shell. Parse the command AST. Apply authorization rules to the parsed structure (command name, flags, arguments, pipes, redirections) rather than the serialized string.
• Role-based authorization first. Define a small set of well-understood roles. Let users assign roles. Use fine-grained rules as overrides, not as the primary mechanism.
• Treat this as a combinatorial problem. The space of shell commands is combinatorial (flag permutations, argument orderings, pipe compositions). The authorization model needs to be closed under the same operations — an algebraic approach that compresses the space rather than enumerating patterns.

Impact

This affects every CLI user. The current UX is: approve a command, get prompted again for the same thing, approve again, rules pile up, nothing changes. It erodes trust in the permission system and trains users to just approve everything — the opposite of the intended security outcome.