**Version:** 2.1.198 **Platform:** Linux (Debian 12), bash **Renderer:** fullscreen TUI (`"tui": "fullscreen"` in `~/.claude/settings.json`) **Config:** `export CLAUDE_CODE_DISABLE_MOUSE=1` set in `.bashrc` (verified present in the session's environment) ## Steps to reproduce 1. Launch `claude` with `CLAUDE_CODE_DISABLE_MOUSE=1` in the environment — mouse capture is correctly disabled and native terminal text selection works. 2. With an empty input box, press **Left arrow** — navigates to the

[BUG] Fullscreen TUI: footer navigation (Left/Right arrow) re-enables mouse capture, ignoring CLAUDE_CODE_DISABLE_MOUSE=1

Status Fixed / completed

Reported on v2.1.198

Maintainer reply ✓ Yes — bcherny

Activity 3 comments · opened Jul 2, 2026 · closed Aug 17, 2026

💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

Version: 2.1.198
Platform: Linux (Debian 12), bash
Renderer: fullscreen TUI ("tui": "fullscreen" in ~/.claude/settings.json)
Config: export CLAUDE_CODE_DISABLE_MOUSE=1 set in .bashrc (verified present in the session's environment)

Steps to reproduce

Launch claude with CLAUDE_CODE_DISABLE_MOUSE=1 in the environment — mouse capture is correctly disabled and native terminal text selection works.
With an empty input box, press Left arrow — navigates to the footer/status area (footer:previous).
Press Right arrow — returns to the chat input (footer:next).

Expected

Mouse capture stays disabled; CLAUDE_CODE_DISABLE_MOUSE=1 keeps being honored.

Actual

After returning from the footer, mouse capture is re-enabled (clicks/drag/wheel are captured by Claude Code again and native terminal selection stops working). The CLAUDE_CODE_DISABLE_MOUSE setting is ignored for the rest of the session.

Notes

Reproduces consistently with just the Left-then-Right arrow round-trip.
Possibly related but distinct: #70724 (wheel navigates history with DISABLE_MOUSE on Windows), #71826 (native selection broken by mouse capture on macOS). Neither covers the footer round-trip re-arming capture.

View original on GitHub ↗

3 Comments

NDuggan · 2 months ago

Another casualty of this same fullscreen footer Left/Right round-trip — macOS, 2.1.217.

The footer PR badge loses its OSC 8 hyperlink. Since 2.1.217 made footer PR badges clickable even when hyperlink support can't be auto-detected under tmux (cf. #80081), a freshly-created PR's #NNNN badge is cmd+click-clickable in the in-session footer. Navigating the footer with the Left/Right arrows drops the OSC 8 anchor: #NNNN degrades to plain text and stays non-clickable for the rest of the session. The same PR stays clickable in the claude agents dashboard (re-rendered fresh on each entry), so the URL/data is intact — it's the in-session footer re-render after nav that loses the anchor.

Environment: Claude Code 2.1.217 · macOS · iTerm2 · tmux 3.5a · "tui": "fullscreen". Note: background sessions always use the fullscreen renderer while attached, so /tui default isn't an available workaround here.

Repro:

A session with a clickable footer PR badge, plus a running pipeline monitor in the footer (I hit it with the monitor present — haven't confirmed whether the monitor is required or whether the plain empty-input Left→Right round-trip is enough).
Down-arrow into the footer to the monitor item, then press Left/Right arrow.
→ #NNNN becomes plain text; no longer cmd+click-clickable; persists for the rest of the session.

Same trigger as the mouse-capture re-arm reported here, different casualty — looks like the footer-nav round-trip re-emits the footer without re-applying its OSC 8 anchors. Possibly related: #75899 (left-arrow footer/agents nav leaving the session view degraded on return).

bcherny collaborator · 2 months ago

Thanks for the detailed report and repro steps — this was a real bug, and it's already fixed.

I ran your exact scenario on the current release 2.1.233 on Linux (tmux, "tui": "fullscreen", CLAUDE_CODE_DISABLE_MOUSE=1, terminal output captured with script): launch, press Left at the empty prompt (opens the agents view), press Right to return, then exit. Scanning the captured byte stream, no mouse-tracking enable sequences (ESC[?1000h/1002h/1003h/1006h) appear at any point — mouse capture stays disabled and native selection keeps working after the round-trip.

The underlying cause was that background/attached sessions ignored the CLAUDE_CODE_DISABLE_MOUSE / CLAUDE_CODE_DISABLE_MOUSE_CLICKS opt-outs, and the Left-then-Right navigation goes through that path. This was fixed in 2.1.203 — see the changelog.

Closing as fixed — please update to 2.1.203 or later and reply here if you still see mouse capture come back after the arrow-key round-trip, and we'll reopen.

🤖 Generated with Claude Code

github-actions[bot] · 9 days ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.