TUI: click-to-select fires even when the TUI window lacks focus — should require focus-first

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

1. Open two Claude Code TUI windows side-by-side
2. 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
3. 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

• This is in the same family as the timestamp-rendering UX gap filed as #70825 — the multi-window scrollback experience suffers from rendering decisions that work fine for a single window but compound friction at scale.

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