Fullscreen TUI is repeatedly re-prompted and force-enabled on background session attach, overriding explicit user opt-out

Status Open

Reported on v2.1.191

Maintainer reply None cached

Activity 3 comments · opened Jul 3, 2026

Environment

Claude Code 2.1.191, macOS (Darwin 25.3.0, arm64), Ghostty

Summary

The fullscreen renderer (research preview) enables xterm mouse reporting, which takes over native terminal behaviour: text selection by drag, middle-click paste and link clicks all stop working. I have declined the fullscreen opt-in prompt multiple times across recent versions, yet:

The opt-in prompt keeps coming back after updates, and
Background sessions ignore the preference entirely. Attaching to a background session always uses the fullscreen renderer with mouse capture. Running /tui default inside one responds: "Background sessions always use the fullscreen renderer so scrolling and mouse work when attached. The tui setting applies to sessions started directly with claude."

The result is that a user who has explicitly and repeatedly said no still loses native mouse behaviour, with no indication of why, and has to diagnose stuck mouse-reporting mode themselves. It cost me a debugging session to trace selection/middle-click/link breakage back to this feature.

Expected behaviour

Do not change how a user's terminal behaves without their awareness. Everyone has their own TUI preference and runs their terminal the way they want - mouse handling, selection and paste belong to the user's terminal setup, not the app. Concretely:

Declining an opt-in should be remembered. Re-prompting the same user after each update treats paying users as feature testers.
A user preference (tui: "default" or a declined prompt) should be honoured in ALL session types. If background attach genuinely requires the alt-screen renderer for virtualised scrollback, degrade gracefully for opted-out users: keyboard scrolling without mouse capture, rather than silently re-enabling what was declined.
CLAUDE_CODE_DISABLE_MOUSE should be a first-class documented setting (settings.json key, /config toggle), not an env-var escape hatch buried in the fullscreen docs.

Workaround

~/.claude/settings.json:

{
  "tui": "default",
  "env": { "CLAUDE_CODE_DISABLE_MOUSE": "1" }
}

Repro

Decline the fullscreen renderer prompt (or set /tui default)
Start a background session and attach to it in Ghostty (or any terminal)
Try to drag-select text, middle-click paste, or click a link - all captured by the app
Run /tui default inside the attached session - it reports the setting does not apply to background sessions

View original on GitHub ↗

3 Comments

OndrejSto · 3 months ago

+1. Same on kitty 0.32.2 / Linux, Claude Code v2.1.205.

Concrete data point: in a session started directly with claude (fullscreen
renderer), mouse click-drag selection works well for me — it's the in-app,
format-aware selection that copies clean logical text on release. The moment I
go through agent view (attach, or hop into another agent and back into the
session), that selection breaks: I'm back to needing Shift-drag, which in kitty
grabs full terminal-width lines instead of the logical selection. /tui default
inside the attached session reports it doesn't apply to background sessions,
exactly as described here.

So for those of us who actually like the fullscreen in-app selection, the
problem isn't fullscreen itself — it's that attach / agent-view round-trips
don't give the same working selection that a direct fullscreen session does,
and there is no way to make the renderer/mouse preference stick across attach.

Request, echoing the above: honor the user's tui/mouse preference in attached
and agent-view sessions too (or at least make an attached session behave like a
direct session for selection), and surface CLAUDE_CODE_DISABLE_MOUSE as a
first-class settings.json / /config option rather than an env-var-only escape
hatch. Being unable to use agent view without losing text selection is a real
blocker for a multi-session workflow.

root- · 1 month ago

Also reproduces via claude logs <id>, not just claude attach — and cleanup on exit is broken, not just the forced fullscreen itself.

Environment: Claude Code 2.1.233, Windows 11 + WSL2 (Ubuntu)

Repro:

Have a completed background session (state: "done") from claude agents --json --all.
Run claude logs <id> from a fresh terminal.
Instead of printing recent output and exiting (as the command is documented to do), the terminal switches into what looks like the same fullscreen/attach view described above, with mouse tracking enabled.
Moving the mouse or scrolling floods the input prompt with raw SGR mouse-report escape sequences (position/click data) as literal text.
Exiting with Ctrl+C x2 does not restore terminal state — mouse tracking stays on. Only running reset or stty sane in the same terminal fixes it.

groupsky · 1 day ago

Same on Linux: Claude Code 2.1.296, Ubuntu X11, gnome-terminal (VTE). tui is "default" and my normal claude sessions use the classic renderer, but claude attach <id> always opens fullscreen with mouse capture on. Every mouse action needs Shift: selecting text, and right-click on a link (the terminal's "Open Link" / "Copy Link" menu). The changes sidebar also shows on attach, and for a session that edits no files it is always empty.

Please make attach respect tui: "default", or at least let me turn off mouse capture there.