[BUG] Mouse click on menu option intermittently misses (middle option) — hit-testing appears to race with re-render during streaming

Environment

• Claude Code version: 2.1.201
• Platform: Linux (Ubuntu, kernel 6.8), X11
• Terminal: agentboy — an Electron + xterm.js 5.5 terminal (DOM renderer), TERM=xterm-256color, SGR mouse reporting

Bug description

With the new mouse click-to-select support in menus, clicking an option in interactive prompts (permission prompts, AskUserQuestion choice menus) intermittently does not register — most often the middle option (e.g. option 2 of "1. Yes / 2. Yes, and don't ask again / 3. No"), while clicking options 1 and 3 works. Retrying the click on option 2 keeps failing during that episode; later, the same kind of prompt works fine.

What we ruled out (terminal-side evidence)

Since the host terminal is our own xterm.js app, we first suspected our click→cell mapping and tested it headlessly (Xvfb + xdotool + a mock TUI that echoes SGR mouse reports and draws a marker at the exact cell it received):

• A 92-click vertical sweep across the whole screen: every click was received and mapped to the correct cell, row boundaries perfectly uniform, no drift, no dead zones.
• Repeated after changing font size (fractional line-height cell metrics): still pixel-perfect.

So the escape sequences delivered to Claude Code contain the correct cell coordinates.

Live repro attempts inside Claude Code

• AskUserQuestion with a deliberately long option 2 (soft-wrapped): clicking it works when the UI is idle.
• Permission prompt for a command: clicking option 2 works when the UI is idle.
• The failures were observed while the assistant's turn was still active — output streaming in / the Ink UI re-rendering above or around the prompt.

Hypothesis

Click hit-testing appears to race with re-rendering: the click is resolved against the row where the option was rendered a moment earlier, so after a reflow/re-render the click misses (or hits a neighbouring row). Middle options are the most affected because a ±1 row error from an edge option still lands inside the menu, while the middle option's own row has moved.

Steps to reproduce (best effort — timing dependent)

1. Run a session where the agent produces streaming output and then shows a permission prompt (3 options, option 2 being the long "don't ask again" one).
2. While the transcript above the prompt is still updating/re-rendering, click option 2 with the mouse.
3. Observed: nothing happens (or a neighbouring option reacts); options 1 and 3 remain clickable. Once the UI settles, clicking option 2 works again.

Expected

A click on a visible option should select that option, or hit-testing should be re-anchored after every render so a click during/just after a re-render cannot resolve against stale row positions.

Related

Possibly related to the recent "Added mouse click support to select menus" change and #70685 / #70672 / #72614, but this report is specifically about clicks missing an option (stale hit-testing), not about accidental selections.

---

Investigated and drafted with Claude Code itself (Claude Fable 5) running inside the affected session; the terminal-side probe used for the evidence lives at agentboy/scripts/headless-click-probe/.