Fixed role-based numeric hotkeys (1/2/3) for permission prompts — consistent, fast, safer
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
--dangerously-skip-permissionsflag: 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.
- 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.
- Just clicking faster: This is what I do now. But after 50+ prompts, fatigue leads to misclicks — especially when
2means "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
- I ask Claude Code: "Rename the
utils/formatDatemodule toutils/dateFormatteracross the entire codebase" - Claude identifies 15 files that import this module
- Claude asks permission to READ
src/components/Header.tsx→ I press1(Allow once) - Claude asks permission to WRITE
src/components/Header.tsx→ I press1(Allow once) - This repeats for all 15 files = ~30 prompts
- At prompt #12, Claude asks a 2-option prompt (no batch available). With the CURRENT system,
2now means Deny instead of Allow All. I press2out of habit → operation denied, flow broken, I have to re-request. - With the PROPOSED system, I press
2→ nothing happens (batch not available). I press1→ allowed. Or I press3→ 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 |
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗