Permission dialog: add mid-granularity live controls (directory/session scoping)

Problem

The permission dialog currently offers three options when Claude requests to use a tool:

1. Allow once — approve this single action
2. Allow for session (or "Allow all") — approve all actions of this tool type
3. Deny

There's no middle ground. In practice — especially while learning or reviewing — I often want something like:

• "Allow edits in src/ for this session"
• "Allow edits to .ts files but keep prompting for config files"
• "Allow all git commands except push"

The granularity exists in settings.json (allow/ask/deny rules with glob patterns), but there's no way to create scoped rules from within the live permission dialog without breaking flow.

Proposed Solution

Replace the current flat list of options with a compact default + expandable detail pattern:

Default view (unchanged feel)

Claude wants to edit src/components/Header.tsx

  [Allow once]  [Allow for session]  [Deny]
                        ▸ More options

Expanded view (on "More options")

Reveals scoping controls across multiple dimensions. Each is independent and combinable:

Claude wants to edit src/components/Header.tsx

  Scope this permission:

  ┌─ What ──────────────────────────────────────┐
  │ ○ This exact action only                    │
  │ ○ This tool (Edit)                          │
  │ ○ This tool + Bash                          │
  │ ○ All tools                                 │
  └─────────────────────────────────────────────┘

  ┌─ Where ─────────────────────────────────────┐
  │ ○ This file only                            │
  │ ○ This directory (src/components/)          │
  │ ○ This file type (*.tsx)                    │
  │ ○ Entire project                            │
  └─────────────────────────────────────────────┘

  ┌─ How long ──────────────────────────────────┐
  │ ○ Once                                      │
  │ ○ This session                              │
  │ ○ Save to project settings                  │
  │ ○ Save to global settings                   │
  └─────────────────────────────────────────────┘

  [Apply]  [Deny]

Design principles

1. Progressive disclosure. The default collapsed view looks and behaves exactly like today. Users who never expand it see no change.
2. Dimensions are independent. "This tool + This directory + This session" is a valid combination. So is "All tools + This file + Once." The system composes them.
3. Ordered by constraint. Within each dimension, options go from most constrained (top) to most free (bottom). This nudges toward minimal grants.
4. Generates real rules. The expanded selection maps directly to existing allow/ask/deny rule syntax. "Save to project settings" literally writes "Edit(src/components/**)" into .claude/settings.json. No new permission engine needed — just a UI that writes to the existing one.
5. Smart defaults. The expanded view pre-selects options matching the current action (tool = Edit, directory = the file's parent, duration = session), so a user can just tweak one dimension and hit Apply.

Example compositions

| Selection | Generated rule | Saved to |
|-----------|---------------|----------|
| Edit + This directory + Session | Session allow: Edit(src/components/**) | In-memory |
| Edit + *.tsx + Project settings | "allow": ["Edit(**/*.tsx)"] | .claude/settings.json |
| Bash + This file type + Once | Allow this one action | Nothing persisted |
| All tools + Entire project + Global | "allow": ["Edit", "Bash"] | ~/.claude/settings.json |

Prior Art / Ecosystem Context

Several third-party projects are building toward this from the hooks/MCP side:

• CCO-MCP — web dashboard for real-time tool approval via --permission-prompt-tool
• kornysietsma/claude-code-permissions-hook — Rust PreToolUse hook with regex-based directory/command scoping
• rulebricks/claude-code-guardrails — cloud-based visual rule editor with live mid-session updates
• M87-Spine-lite — governance layer with native directory scoping and posture escalation

The hooks API (PreToolUse, --permission-prompt-tool) makes it possible to build this externally, but a first-party solution integrated into the TUI would be far more accessible — especially for users who aren't yet comfortable writing hooks or configuring MCP servers.

Related Issues

• #15041 — Mid-session permission mode switching
• #14044 — Switching permission modes from hooks
• #22292 — Persistent permission preferences across sessions
• #18699 — "Allow always (save to settings)" option
• #4719 — Expose active permission mode to hooks

Current Workarounds

• Shift+Tab to toggle between default and acceptEdits — binary, no scoping
• /permissions to add rules mid-session — works but breaks flow
• Pre-configured settings.json rules — requires knowing the pattern in advance
• Third-party hooks — powerful but high setup cost

🤖 Generated with Claude Code