Claude Code: caret cursor and no mouse clicks on prompts (mouse reporting never reaches xterm) #182

Owner, 2026-10-11 (their words): "right now in claude code the cursor is always the caret cursor, it should be the normal cursor ... i cant use my cursor to click things, like when there comes permission prompts, you usually can use the mouse to click yes or no but now that doesnt work and you have to use your keyboard". Not sure whether it is permanent or comes and goes.

What was found (read-only code investigation, main at a38e05b, 2026-10-11)

Confirmed from code

• The caret is xterm's own default: .xterm { cursor: text }, and .xterm.enable-mouse-events { cursor: default } only once xterm itself has accepted a mouse mode (DECSET 1000/1002/1003). No CSS in core/ or src/ sets a cursor. So a caret over Claude means xterm's mouseTrackingMode is none: the mouse-on request never reached it.
• Prism Terminal does not block it: every CSI handler it registers on those modes returns false (passes through) (TerminalPanel.tsx click-caret hooks, the A theme switch is never passed on to Claude (mode 2031 / DSR 997) #172 theme-mode hook, RIS), and the resume clear resets no modes.
• It does not swallow clicks either: click-to-move-caret listens in capture but never calls preventDefault/stopPropagation, and stands down when a program owns the mouse.
• Claude Code does ask for the mouse here ("tui": "fullscreen", no CLAUDE_CODE_DISABLE_MOUSE*).
• The click direction was already known to fail on 2026-09-28: wip/mouse-report-e2e (09e0dbc, never merged) adds a mouseReport e2e and notes "without the win32-input-mode wrapping the bundled ConPTY ate the report whole". No wrapping code exists on any branch.

Likely, not yet verified

• The bundled ConPTY (node-pty's, 1.25.260303002) drops Claude's mouse-on request (ConPTY forwards it only when the program's console input is in VT mode), and drops raw SGR clicks on the way back. If so it is permanent for this Claude + ConPTY pair, not tied to a resize, a restored tab or a setting.
• Not obviously a regression from fix(core): Claude Code compatibility fixes (#167-#177) #178 (515d6d0). The one recent change that could matter is No XTVERSION reply, so Claude never turns on synchronized output (DEC 2026) #171 answering XTVERSION, which lets Claude detect the terminal; nothing found links it to the mouse.

To confirm first

1. With Claude's full-screen view open, in DevTools: document.querySelector('.xterm').classList.contains('enable-mouse-events').
2. Log raw term:data and look for \x1b[?1000h / \x1b[?1006h. Absent: ConPTY dropped it. Present but no class: the fault is in xterm or the app.
3. Compare with Windows Terminal (and Tabby) on the same Claude version.

Fix direction

• Output side: get the request through (ConPTY / node-pty version, or upstream fix). The app must not switch mouse mode on by itself.
• Input side: when a program owns the mouse, send clicks in the form ConPTY accepts (win32-input-mode wrapped), in core/ (so Prism gets it, core bump).
• Test: finish and merge the mouseReport e2e from 09e0dbc, plus a check that .xterm has enable-mouse-events and a default cursor after the probe turns mouse mode on, and a probe on Claude's real runtime (Bun), not only Node.