What
When the Claude Code TUI window does NOT have focus and the user clicks an interactive element (a message bullet, a tool-result expand, a button), the click both (a) focuses the window AND (b) immediately selects/activates the item under the cursor.
Expected (and the platform convention on macOS, modern Wayland compositors, and most "focus-stealing-avoidant" UIs): the FIRST click on an unfocused window only focuses it. The user has to click again — now with the window confirmed focused — for the action to register.
Why it matters
Real-world scenario from a power user running several Claude Code TUI windows side-by-side:
"I have multiple windows open and regularly now select the wrong item when trying to shift focus."
In a multi-window workflow (one terminal per active session/agent), every focus switch is currently a risk: if the cursor happens to land on a selectable element, you accidentally act on it. Often the user notices a beat too late — the session has already expanded a tool result, jumped to a different message, or worse.
This behaviour also recently changed (the user remembers it not always being this way), which makes the regression noticeable and frustrating.
Reproduction
- Open two Claude Code TUI windows side-by-side
- Click in Window A, do something, then click in Window B (which lacks focus) — specifically click on a message bullet, a tool-call expand control, or any selectable element
- Window B both focuses AND treats the click as a selection on the item under the cursor
Desired behaviour
- On an unfocused TUI window, the first click only focuses the window. The click is consumed.
- A second click is required to act on an element.
- Ideally configurable via
~/.claude/settings.json, but the default should be focus-first (the macOS-standard, principle-of-least-surprise behaviour).
Suggested settings shape:
{
"tui": {
"clickThroughOnUnfocused": false
}
}(false = focus-first; true = current behaviour for users who prefer it.)
Related
Acceptance criteria
- Click on a TUI window that does not have focus consumes the click without activating any element beneath the cursor
- Second click activates as normal
- Behaviour is the default, with optional opt-in to the current click-through behaviour via settings
What
When the Claude Code TUI window does NOT have focus and the user clicks an interactive element (a message bullet, a tool-result expand, a button), the click both (a) focuses the window AND (b) immediately selects/activates the item under the cursor.
Expected (and the platform convention on macOS, modern Wayland compositors, and most "focus-stealing-avoidant" UIs): the FIRST click on an unfocused window only focuses it. The user has to click again — now with the window confirmed focused — for the action to register.
Why it matters
Real-world scenario from a power user running several Claude Code TUI windows side-by-side:
In a multi-window workflow (one terminal per active session/agent), every focus switch is currently a risk: if the cursor happens to land on a selectable element, you accidentally act on it. Often the user notices a beat too late — the session has already expanded a tool result, jumped to a different message, or worse.
This behaviour also recently changed (the user remembers it not always being this way), which makes the regression noticeable and frustrating.
Reproduction
Desired behaviour
~/.claude/settings.json, but the default should be focus-first (the macOS-standard, principle-of-least-surprise behaviour).Suggested settings shape:
{ "tui": { "clickThroughOnUnfocused": false } }(
false= focus-first;true= current behaviour for users who prefer it.)Related
Acceptance criteria