[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

View original on GitHub ↗

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