[FEATURE] Execution confirmation prompts block user input - suggest non-blocking UI design
Resolved 💬 3 comments Opened Apr 13, 2026 by EMarkODell Closed Apr 16, 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
Currently, when Claude Code requests execution confirmation (yes/no
prompts), the interface blocks all user typing until the confirmation is
answered. This interrupts workflow and prevents users from continuing to
compose thoughts or commands.
Proposed Solution
Separate execution confirmation requests into a dedicated UI area (e.g.,
sidebar or separate block) that doesn't share screen space with the main
input field. Users could:
- Continue typing in the main input area at all times
- Use up/down arrows to shift focus to the confirmation area when ready
- Submit yes/no answer, which auto-returns focus to main input
- Never be blocked from typing unless explicitly choosing to focus on the
confirmation prompt
Alternative Solutions
no effective work-around
not noticing switch to yes/no request means typing to oblivion
lost input
Priority
High - Significant impact on productivity
Feature Category
CLI commands and flags
Use Case Example
_No response_
Additional Context
Benefits
- Non-blocking workflow
- Allows users to continue composing while considering execution requests
- Better separation of concerns (input vs. confirmation)
- More flexible interaction model
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗