[BUG] Attach to background session never enables mouse tracking — wheel becomes arrow keys (still in 2.1.252, byte-level evidence)

Summary

Attaching to a background session (claude --bg + claude attach <id>, /bg + reattach, or opening one from Agent View) puts the terminal into the alternate screen without ever enabling mouse tracking. Any terminal that implements the alternate-scroll fallback (VS Code integrated terminal, Windows Terminal, most Linux terminals) then converts wheel events into arrow keys, so the wheel cycles input history instead of scrolling the transcript, and Claude Code shows "Scroll wheel is sending arrow keys · use PgUp/PgDn to scroll". Hover/click and Claude-managed select-to-copy are also dead; selection falls back to native terminal copy.

This is the same defect as #59979 (closed as fixed in 2.1.144, but reported as still reproducing in 2.1.176/2.1.183/2.1.195 by multiple users) and #64214 (Linux). I captured the raw bytes each code path writes, on both 2.1.241 and 2.1.252 (latest, build 2026-08-31, c0778c4): the captures are byte-identical in the relevant modes — the bug is still present in 2.1.252.

Environment

• Claude Code 2.1.241 and 2.1.252 (native installer, win32-x64)
• Windows 10 Pro 19045
• Reproduced in the VS Code integrated terminal (TERM_PROGRAM=vscode, 1.134.0) and under a bare ConPTY harness (pywinpty), so this is not VS Code-specific
• Foreground fullscreen sessions on the same machine work perfectly

Reproduction

1. claude --bg "anything" → note the session id
2. claude attach <id> (or open it via claude agents)
3. Scroll the mouse wheel → arrow keys / prompt-history cycling; the "use PgUp/PgDn" hint appears. PgUp/PgDn do work.

Byte-level evidence (DEC private modes written to the terminal, in order)

Foreground fullscreen session (wheel works):

?1004h ?9001h ?1049h ?1000h ?1002h ?1003h ?1006h ?25l ?2004h ?2031h ?2026h/l …

claude attach to a background session (wheel broken) — identical on 2.1.241 and 2.1.252:

?1004h ?9001h ?1049h ?2004h ?1004h ?2031h ?25l ?2026h/l …        ← no mouse modes at all

The hosted background worker itself (captured via CLAUDE_PTY_RECORD on the PTY host):

?1004h ?2004h ?25l …                                             ← inline renderer: no alt screen, no mouse

Analysis

• The attach client enters the alt screen and then replays only the DEC private modes the daemon tracked from the hosted worker (the decModes array in the attach ack).
• The hosted worker always runs the inline renderer, which never enables mouse tracking — so no mouse mode is ever replicated to the attaching terminal.
• Alt screen active + no mouse tracking is exactly the state where xterm.js/Windows Terminal/etc. fall back to alternate-scroll: wheel → CSI A/CSI B.
• The existing self-heal (arrow-burst detection → reassertTerminalModes) is a no-op here, because it re-asserts the worker's mouse mode, which is "off".
• This also explains the macOS/Linux asymmetry in #64214: nothing in the attach path enables mouse reporting, so behavior is entirely determined by each terminal's alt-screen wheel fallback.

Suggested fix directions

• Have the attach client enable SGR mouse reporting itself (as the foreground fullscreen renderer does) and translate wheel reports into the existing scroll pipeline; or
• Have the daemon synthesize mouse modes into decModes for attach and route the resulting SGR wheel input to the transcript scroller in the hosted worker.

Happy to provide the full capture logs or run diagnostics on a candidate build — this machine reproduces it 100% of the time.