Fixed role-based numeric hotkeys (1/2/3) for permission prompts — consistent, fast, safer

Resolved 💬 2 comments Opened Apr 1, 2026 by fevzigunalp Closed May 29, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

During intensive Claude Code sessions (multi-file refactoring, systematic edits, rapid prototyping), I encounter 50-80 permission prompts in a 30-minute session. Each one breaks my flow for 3-5 seconds, totaling 4-6 minutes of pure friction.

But the deeper problem is inconsistent option mapping. Currently Claude Code uses sequential numbering:

3-option prompt: 1=Allow, 2=Allow All, 3=Deny
2-option prompt: 1=Allow, 2=Deny

This means pressing 2 sometimes approves everything, sometimes denies. This is dangerous for muscle memory — a user building the habit of 2=Allow All will accidentally deny actions when the prompt switches to 2-option mode, or worse, the reverse.

Real example: I was renaming a module across 15 files. ~30 permission prompts. By prompt #10, I was on autopilot. If I had built muscle memory for 2=Allow All from 3-option prompts, I would have accidentally denied half my operations when 2-option prompts appeared.

I know --dangerously-skip-permissions exists, but it's all-or-nothing. I want to keep the safety model — I just want consistent, fast responses.

---

📊 Impact Analysis: Current System vs Proposed System

⏱ Time Cost

| Metric | Current System | Proposed (Role-Based Hotkeys) | Improvement |
|--------|---------------|-------------------------------|-------------|
| Time per prompt | 3-5 sec (read + navigate + confirm) | 0.5 sec (digit + Enter) | ~85% faster |
| 30-min session (60 prompts) | 3-5 min lost | ~30 sec lost | ~4 min saved per session |
| Daily (3 hours heavy use) | 18-30 min lost | ~3 min lost | ~25 min saved per day |
| Monthly (22 work days) | 6.6-11 hours lost | ~1.1 hours | ~8 hours saved per month |

⚠️ Misclick / Wrong Action Risk

| Scenario | Current (Sequential) | Proposed (Role-Based) |
|----------|---------------------|----------------------|
| User builds muscle memory for 2=Allow All | ❌ DANGEROUS: In 2-option prompts, 2=Deny. User accidentally rejects. | ✅ SAFE: 2 always=Allow All. If not available, 2 does nothing. |
| User builds muscle memory for 3=Deny | ❌ BROKEN: 3 only exists in 3-option prompts. | ✅ CONSISTENT: 3 always=Deny, everywhere. |
| Fatigue after 50+ prompts (autopilot mode) | ❌ HIGH RISK: ~30% of prompts switch layout. Estimated 5-10% wrong action rate. | ✅ LOW RISK: Fixed mapping. Estimated <1% error rate. |

🧠 Cognitive Load

| Factor | Current | Proposed |
|--------|---------|----------|
| Must read prompt options? | Yes, every time | No — fixed mapping, press by reflex |
| Mental model complexity | 2 different mappings | 1 universal mapping |
| Flow state interruption | Full stop | Minimal reflex |
| Non-English speaker overhead | Must parse English each time | Numbers are universal |

Proposed Solution

Assign fixed, role-based numeric hotkeys where each number ALWAYS means the same action, regardless of how many options are shown:

| Hotkey | Role (FIXED) |
|--------|-------------|
| 1 | Allow once |
| 2 | Allow all (batch approve) |
| 3 | Deny |

Key design principle: When a prompt only has 2 options (no batch), show 1 and 3 — skip 2. Do NOT renumber sequentially.

Example — 3-option prompt:

Alternative Solutions

  1. --dangerously-skip-permissions flag: I've tried this, but it's all-or-nothing. Skipping ALL permissions removes the safety net entirely. I still want Claude to ask — I just want to answer faster.
  1. Allowlisting specific tools/paths in settings: Partially helps, but doesn't cover dynamic scenarios where Claude needs to touch unexpected files. And setup overhead is high for each new project.
  1. Just clicking faster: This is what I do now. But after 50+ prompts, fatigue leads to misclicks — especially when 2 means "Allow All" in one prompt and "Deny" in the next. The inconsistency makes speed dangerous.

None of these solve the core problem: the permission system is designed for careful deliberation, but real-world usage is rapid-fire reflex responses.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

Scenario: Renaming a shared utility module across a TypeScript monorepo

  1. I ask Claude Code: "Rename the utils/formatDate module to utils/dateFormatter across the entire codebase"
  2. Claude identifies 15 files that import this module
  3. Claude asks permission to READ src/components/Header.tsx → I press 1 (Allow once)
  4. Claude asks permission to WRITE src/components/Header.tsx → I press 1 (Allow once)
  5. This repeats for all 15 files = ~30 prompts
  6. At prompt #12, Claude asks a 2-option prompt (no batch available). With the CURRENT system, 2 now means Deny instead of Allow All. I press 2 out of habit → operation denied, flow broken, I have to re-request.
  7. With the PROPOSED system, I press 2 → nothing happens (batch not available). I press 1 → allowed. Or I press 3 → denied. No ambiguity, no accident.

Alternative fast path: At prompt #1, I press 2 (Allow All for this type) → remaining 14 read operations are auto-approved. Then at the first write prompt, I press 2 again → remaining 14 writes auto-approved. Total: 2 keystrokes instead of 30 prompts. Session time: 10 seconds instead of 3 minutes.

Additional Context

  • OS: Linux / macOS terminal
  • Plan: Max plan
  • Daily usage: 3+ hours of active Claude Code use
  • Primary workflow: Multi-file refactoring, codebase-wide renames, systematic migrations
  • Language: Non-English speaker (Turkish) — text-based options add cognitive overhead; numbers are universal

Summary of projected impact:

| Metric | Improvement |
|--------|-------------|
| Time per prompt | ~85% faster (3-5s → 0.5s) |
| Monthly time saved | ~8 hours |
| Wrong action rate | ~90% reduction |
| Flow interruptions | ~85% reduction |

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗