blast-radius-permissionlisted

# Blast Radius Permission ## Overview A permission system is not just a yes-or-no gate. It is a layered judgment about who bears the risk, how wide the action's blast radius is, and which safeguards must remain active even in autonomous modes. ## Source Anchors - `src/utils/permissions/permissions.ts` - `src/utils/permissions/permissionSetup.ts` - `src/components/permissions/` ## Workflow 1. Gather every rule source first: user settings, project settings, local settings, session rules, and CLI grants. 2. Evaluate rule-based deny and ask decisions before tool-specific permission checks. 3. Treat content-specific ask rules and safety checks as bypass-immune so fast modes cannot skip them. 4. Apply mode behavior next, including bypass, accept-edits, plan, and auto. 5. Before entering auto mode, strip dangerous allow rules such as `Bash(*)`, `PowerShell(iex:*)`, or `Agent(*)` that would bypass the classifier. 6. Let safely sandboxed commands use the sandbox fast path and route the rest through classifier or explicit user approval. 7. Track classifier source, reason, cost, and repeated denials so the system can fail closed or fall back to prompting in a controlled way. 8. Model permission persistence explicitly so temporary session grants and durable on-disk grants do not get confused. ## Design Rules - Ask who is affected before asking whether the command can technically run. - Preserve source metadata for every allow, ask, and deny decision so behavior is explainable. -