[FEATURE] Non-intrusive prompts — stop stealing focus from active typing (52 related reports, consolidated)

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

A dialog, popup, or panel steals keyboard focus while the user is actively typing — text is lost,
misdirected, or a wrong option fires. Found 52 related reports over 14+ months (2025-06-04 to
2026-08-14), spanning Claude Code's own terminal UI, the VS Code extension, the JetBrains plugin, the
desktop app, and the TUI. 18 still open. None reference each other as a group.

Three prior feature requests already named this exact problem, all now closed: #10971 ("Prevent
prompts and dialogs from appearing while user is actively typing," closed not-planned, has the clearest
5-point framing of anything found — its proposed fix was briefly implemented in v2.1.138 per #63558 below,
then a later release removed it), #32726 (VS Code-scoped, asks for an opt-out setting), and #59336
(TUI-scoped, "shouldn't steal focus," 4 👍, tagged stale). None were promoted into a tracker; none link the
other two.

Earliest report found: #1591, 2025-06-04 — "claude in webstorm's terminal... auto-focuses all the time
to the terminal, and i lose the cursor on the editor." All 52 relate to the same root behavior — nothing in
the input path checks for active typing before a new UI element claims focus — with varying overlap between
reports (see table below).

Found 6 trigger types across the 52 existing reports, plus a 7th I hit myself with no matching report:

| # | Trigger | # issues | What goes wrong | Examples |
|---|------------------------------------|----------|---------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------|
| 1 | Diff/file-view auto-opens | 8 | Keystroke meant for input hits the diff view instead | #7810, #9765, #14995, #19332, #25988, #38404, #70413, #74549 |
| 2 | AskUserQuestion menu | 10 | Keystroke captured, wrong option fires, duplicate session spawned, or race with buffered input | #8743, #13357, #28722, #35962, #45374, #59336, #75918, #76002, #78185, #86738 |
| 3 | Permission/approval prompt | 15 | Input discarded, wrong option fires, regression from a past fix, or (once) consent auto-accepted -- uploading a full transcript | #18994, #23643, #25073, #33988, #34055, #35337, #37955, #43883, #50923, #62572, #63558, #74814, #75360, #80049, #81224 |
| 4 | @-mention insertion | 2 | Keystroke redirected to the editor tab | #72882, #74808 |
| 5 | Broader terminal/window contention | 15 | General focus fights, not one specific dialog | #1591, #3055, #7618, #13078, #15449, #16732, #23300, #28886, #32726, #45104, #49184, #50899, #72376, #79770, #86477 |
| 6 | Prior consolidation attempts | 2 | Same pattern, closed without being promoted | #31163, #47313 |
| 7 | Cross-thread | 0 | Popup from one thread/agent surfaces in a different thread, unlabeled | None found |

Two of these 52 stand out:

• #74814 — a stray "y" keystroke auto-accepted a transcript-share consent prompt, uploading a full session
• #63558 — v2.1.138 briefly deferred prompts during active typing, exactly the fix #10971 requested, then a later release removed it

Proposed Solution

Don't steal focus from an actively-typing user — ever, automatically. Instead of the prompt/popup taking
over, show a passive indicator (e.g. a blinking/highlighted marker with a link, in the status area) that
something is waiting. The user clicks it when ready, and only then does the prompt/AskUserQuestion/diff
view actually take over. Focus only ever changes on explicit user action, never on a timer or a typing-
pause heuristic — so there's no race with in-flight typing to get wrong in the first place.

• Same-thread case is straightforward (single session, one prompt waiting) — click, it takes over, done.
• Cross-thread case (row 7): don't auto-switch. Point the user to the existing thread-list switcher

(active switch, not auto-send, so context stays clear).

#63558 shows a narrower version of "don't auto-interrupt" worked before (v2.1.138 deferred prompts on
active-typing detection) and was later removed — so the direction is proven, this proposal just removes
the auto-trigger step entirely rather than retiming it.

Alternative Solutions

None found that fully solve it. Partial workarounds exist per-surface (VS Code's insertAtMention
behavior, some diff-tab settings) but nothing addresses the shared root cause across all triggers, per the
table above.

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

1. User is mid-sentence, writing a follow-up message or answering a question
2. Claude Code needs to show a permission prompt, an AskUserQuestion menu, or auto-opens a diff view
3. The new UI element claims keyboard focus without checking whether the user is typing
4. The user's next keystroke(s) go to the new element instead of their intended input — sometimes

selecting an unintended option, sometimes just discarding the typed text with no warning

1. In the most severe case found (#74814), this pattern caused a full session transcript to be

auto-uploaded via an accidentally-accepted consent prompt

Additional Context

Two of these 52 stand out:

• #74814 — a stray "y" keystroke auto-accepted a transcript-share consent prompt, uploading a full session
• #63558 — v2.1.138 briefly deferred prompts during active typing, exactly the fix #10971 requested, then a later release removed it

Treat this as the tracker for the whole class, with the 51 reports in the table above (plus #10971,
#32726, #59336) linked as related manifestations rather than independent reports. 52 reports, a
known-and-lost fix, and a documented data-exposure path seem past the bar for "not planned."

Suggested labels for triage (only enhancement is set automatically by this template):
area:ide (VS Code + JetBrains triggers), area:tui (terminal-TUI triggers), area:permissions (largest
single trigger group), area:a11y (#75360 is an accessibility report), area:security (#74814 is a
data-exposure case).

Happy to help consolidate further if useful.

---
Research and drafting assisted by Claude Sonnet 5 (high effort).