[FEATURE] Save user input to clipboard when permission prompt steals focus

Resolved 💬 4 comments Opened Jan 18, 2026 by Avyukth Closed Feb 28, 2026

[FEATURE] Save user input to clipboard when permission prompt steals focus

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

When Claude Code displays a permission prompt (e.g., tool approval, bash command confirmation) while the user is actively typing, pressing Tab to switch focus to the Yes/No options causes the user's typed input to be lost.

Current Behavior

  1. User is typing a message or additional context in the input field
  2. Claude encounters a permission request (e.g., "Allow bash command?")
  3. Permission prompt appears, but user continues typing (may not notice immediately)
  4. User presses Tab to navigate to the permission options (Yes/No)
  5. All typed content is lost - no way to recover it
  6. User must retype their entire message from memory

Impact

| Issue | Severity |
|-------|----------|
| Lost work/context | High - users lose carefully crafted prompts |
| Frustration | High - repeated occurrences degrade UX significantly |
| Workflow interruption | Medium - breaks concentration and flow |
| Time wasted | Medium - retyping identical content |

Related Issues

  • #10971 - [FEATURE] Prevent prompts and dialogs from appearing while user is actively typing
  • #5005 - Add Clipboard Copy Functionality for Current Prompt

While #10971 proposes queuing prompts during active typing (prevention), this issue proposes a mitigation for when focus switch does occur.

Proposed Solution

When Tab is pressed to switch focus from user input to permission prompt, automatically copy any non-empty input to the system clipboard.

Implementation Details

On Tab key press (when permission prompt is active):
  1. Check if user input field has content (text.length > 0)
  2. If yes:
     a. Copy content to system clipboard (platform-aware)
     b. Display brief notification: "Input saved to clipboard"
  3. Switch focus to permission prompt options

Cross-Platform Clipboard Support

Use existing patterns from the codebase (ref: plugins/plugin-dev/skills/command-development/references/marketplace-considerations.md):

# macOS
pbcopy

# Linux (X11)
xclip -selection clipboard

# Linux (Wayland)
wl-copy

# Windows
clip.exe

# WSL
clip.exe (or /mnt/c/Windows/System32/clip.exe)

User Experience

╭─────────────────────────────────────────────────────────────────╮
│ Allow Bash: npm install express                                 │
│                                                                 │
│ [Yes]  [No]  [Yes, and don't ask again]                        │
╰─────────────────────────────────────────────────────────────────╯
  ℹ Input saved to clipboard                    Tab to switch focus

╭─────────────────────────────────────────────────────────────────╮
│ > I was typing this important context about the task and_      │
╰─────────────────────────────────────────────────────────────────╯

After pressing Tab, user sees notification and can paste (Cmd+V / Ctrl+V) their input back after handling the permission prompt.

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

Scenario: Developer working on a complex refactoring task

  1. User asks Claude to refactor authentication module
  2. Claude starts working, encounters need to run npm install jsonwebtoken
  3. Permission prompt appears: "Allow bash command?"
  4. User, still looking at code/notes, starts typing: "Also make sure to update the middleware to validate tokens and add refresh token support with a 7-day expiry..."
  5. User looks up, sees permission prompt blocking
  6. User presses Tab to select "Yes"
  7. Current behavior: 80+ characters of context lost forever
  8. Proposed behavior: Input copied to clipboard, user pastes after approving, continues seamlessly

Frequency

Based on community feedback in #10971 and #5005, this occurs:

  • Multiple times per session for active users
  • More frequently during complex, multi-step tasks
  • Especially impactful for users who touch-type (eyes on keyboard)

Additional Context

Technical Considerations

  • Clipboard access should be synchronous to avoid race conditions
  • Notification should be non-blocking (auto-dismiss after 2-3 seconds)
  • Consider adding a setting to disable if users prefer not to have clipboard modified
  • Edge case: If clipboard already has important content, consider a "clipboard history" approach or skip

Settings (Optional)

{
  "copyInputOnFocusSwitch": true,  // default: true
  "showClipboardNotification": true  // default: true
}

Accessibility

  • Notification should be screen-reader friendly
  • Consider audio cue option for visually impaired users

---

Related CHANGELOG entries:

  • v2.0.36: "Fixed input being lost when typing while a queued message is processed"
  • v2.0.77: "Improved permission prompt UX with Tab hint moved to footer"

View original on GitHub ↗

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