[FEATURE] Prevent prompts and dialogs from appearing while user is actively typing

Status Closed — not planned
Maintainer reply None cached
Activity 8 comments · opened Nov 4, 2025 · closed Feb 6, 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

Description:

Problem

Claude Code currently displays prompts, permission requests, and other dialogs at any time during execution, including while
the user is actively typing. This creates multiple negative outcomes:

  1. Lost Input: When a dialog appears, focus shifts away from the input field. Any text being typed is lost or interrupted.
  2. Accidental Actions: User pressing Enter to complete their message instead triggers the dialog action they didn't see.
  3. Wasted Time: User must retype their context, question, or clarification from scratch.
  4. Poor UX: Interruption breaks concentration and workflow.
  5. Frustration: Repeated occurrences significantly degrade the user experience.

Current Behavior

  • Dialogs (permissions, confirmations, etc.) appear immediately when Claude encounters them
  • No detection of active user input state
  • Focus shifts to dialog, breaking user's typing flow
  • Typed content during dialog appearance is lost

Technical Considerations

  • Input field should maintain focus during Claude's execution
  • Typing detection should be lightweight and reliable
  • Queue should handle multiple pending dialogs appropriately
  • Visual indicator that dialogs are queued (optional)

Proposed Solution

Desired Behavior

  • Detect active typing: Monitor input field for active typing state
  • Queue all prompts: Hold permission requests, confirmations, and other dialogs when typing detected
  • Display after typing pause: Show queued dialogs only when:
  • User stops typing (500-1000ms delay after last keystroke)
  • User explicitly submits message
  • No active input detected for reasonable timeout

Alternative Solutions

I learn to touch type and stop looking at the keyboard while typing?

This is a significant UX issue that affects every session where users need to provide additional context during execution.
While users could avoid the issue by watching the screen constantly, the tool should adapt to natural user behavior rather than requiring perfect attention.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

Real-World Scenario

  1. User asks Claude to perform a task
  2. User starts typing additional context or clarification (eyes on keyboard)
  3. Claude encounters a permission request or other prompt
  4. Dialog appears, stealing focus
  5. User continues typing but input goes nowhere
  6. User looks up, realizes context is lost
  7. User must dismiss dialog and retype everything

Additional Context

Benefits

  • Preserves user input and context
  • Prevents accidental dialog actions
  • Respects user's focus and workflow
  • Maintains security without interrupting active work
  • Significantly improves overall user experience

View original on GitHub ↗

8 Comments

github-actions[bot] · 11 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/10878
  2. https://github.com/anthropics/claude-code/issues/9765
  3. https://github.com/anthropics/claude-code/issues/8743

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Bodge-IT · 11 months ago

Those issues are similar but this feature request doesn't duplicate them. It specifically looks at CC being aware of user keyboard use to prevent loss of focus at any time user is "interacting", not just specific interruptions. There just shouldn't be any from CC while typing.

github-actions[bot] · 10 months ago

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Bodge-IT · 10 months ago

Still occuring ans till the most annoying UIX failure on the planet. Just burns through time for no reason. You have all the cues.

extemporalgenome · 9 months ago

This still impacts me as well.

My preference would be that it choose not to interrupt based on whether there's a non-empty prompt draft, rather than time-since-last-keystroke. We already have ctrl+s (for stashing the active prompt), and that can hypothetically be used to switch to reviewing any pending dialogs/prompts. Ideally we'd have some statusline or other indicator to show when there are pending prompts.

github-actions[bot] · 8 months ago

This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.

Bodge-IT · 8 months ago

If you're going to close other issues as duplicates of this, it's a bit unfair to then close this.

github-actions[bot] · 8 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.