[BUG] Agents view: opening an existing session requires two clicks on the same row

Summary

In the agents view (claude agents / FleetView), opening an existing background session requires two clicks on the same row: the first click does nothing observable, the second one opens the session. This is reproducible on every row, every time.

I reproduced it outside of any browser or terminal emulator, by driving claude agents inside a raw PTY from Python and injecting SGR mouse reports directly, so the terminal layer can be excluded as a cause.

Environment

• Claude Code 2.1.220 (native install, Linux)
• TERM=xterm-256color, 120x45 PTY
• Reproduced both in a real browser terminal (code-server) and in the headless PTY harness

Steps to reproduce

1. Run claude agents with several existing background sessions listed.
2. Send a single left click on a session row: SGR press ESC [ < 0 ; col ; row M then release ESC [ < 0 ; col ; row m.
3. Observe the screen and ~/.claude/daemon.log.
4. Send the exact same click a second time.

Actual behaviour

• Click #1: no visible change at all (only the unrelated spinner glyphs animate), and no dispatch is recorded in daemon.log.
• Click #2, identical coordinates: full re-render and the session opens, with bg spare spawned host pid=... appearing in daemon.log.

Additional observations that narrow it down:

• Clicking row A once and then row B once opens neither. So this is not merely "the first click focuses the list" — it behaves as select, then activate, per row.
• There is no double-click timing window: 3 seconds between the two clicks still activates, so this is not classic double-click detection.
• Clicking at column 4, 40 or 100 of the row makes no difference — no single-click hotspot on the row.
• The first click produces no visible selection indicator in my capture, so the two-step is not discoverable: it reads as a dropped click.

Expected behaviour

A single click on a session row opens it. If a two-step select-then-activate interaction is intentional, the first click should at least render a clear selection state so the behaviour is discoverable.

What I ruled out

• Terminal / browser layer: reproduced identically in a bare PTY with synthetic SGR mouse reports, no browser involved.
• Background daemon: a successful open logs exactly one bg claimed-spare ... (fleet) line. The only bg: dup dispatch ... dropped (existing handle still live) entries in my log are weeks old and unrelated.
• CLAUDE_CODE_DISABLE_MOUSE_CLICKS: the view enables mouse mode 1000 + SGR 1006 with and without the variable, so it is not the cause. Worth noting separately: when that variable is set, clicks are ignored entirely and the session cannot be opened by clicking at all, even twice.

Keyboard path (secondary, lower confidence)

In my environment I could not open a session from the keyboard either: pressing Down then Enter did not open the highlighted session, and pressing ? appears to be swallowed by the "describe a task for a new session" input rather than opening a shortcuts overlay. The footer hint reads enter to collapse · ctrl+x to delete all · ? for shortcuts. I may be missing the intended key binding, but combined with the mouse behaviour it means there is no obvious one-action way to open an existing session.

Impact

Every session open costs two clicks. For anyone running many background sessions, this doubles the interaction cost of the primary action in this view.

Related but distinct

• #76528 (configurable mouse interaction levels for interactive prompts)
• #70539 (scroll-only mouse mode)

Neither covers the agents view requiring two clicks to open a session.