[FEATURE] Save user input to clipboard when permission prompt steals focus
[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
- User is typing a message or additional context in the input field
- Claude encounters a permission request (e.g., "Allow bash command?")
- Permission prompt appears, but user continues typing (may not notice immediately)
- User presses Tab to navigate to the permission options (Yes/No)
- All typed content is lost - no way to recover it
- 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
- User asks Claude to refactor authentication module
- Claude starts working, encounters need to run
npm install jsonwebtoken - Permission prompt appears: "Allow bash command?"
- 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..."
- User looks up, sees permission prompt blocking
- User presses Tab to select "Yes"
- Current behavior: 80+ characters of context lost forever
- 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"
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗