New scroll UI breaks tmux copy mode workflow (scrollback no longer accessible)

[Yashas2801]

Description

Since the introduction of the internal scroll viewport (visible as the "Jump to bottom (ctrl+End)" button), Claude Code output no longer goes into tmux's scrollback buffer. This breaks a common terminal workflow where users enter tmux copy mode and navigate output using vim motions.

Previous behavior

Claude Code output was written to stdout → went into tmux's scrollback buffer → users could enter copy mode (Prefix + [) and use vim motions (j/k, C-u/C-d, G, /search) to navigate and select text comfortably.

Current behavior

Claude Code now manages its own scroll viewport. Output does not appear in tmux's scrollback. Entering copy mode shows an empty or stale buffer — the Claude Code content is inaccessible via copy mode entirely. The only way to scroll is via touchpad or mouse wheel within Claude Code's own UI.

Impact

This is a regression for keyboard-driven / tmux-heavy workflows. Copy mode + vim motions is significantly more efficient than reaching for a mouse to scroll through long responses.

Suggested fix

Add a flag or config option to disable the internal scroll viewport and revert to writing output directly to stdout/scrollback:

• CLI flag: --no-scroll-ui or --no-alternate-screen
• Settings key: "scrollUI": false

Environment

• Claude Code version: 2.1.143
• OS: Linux (Arch), kernel 6.18.9
• Terminal: tmux with set -g mouse on, mode-keys vi
• Shell: zsh

[henricook]

Even if a plain terminal, like Terminator, the mouse scroll is now super slow - it takes 3x as many scrolls to reveal the same amount of text which is immensely frustrating!

[tandrewnichols]

The more frustrating part of this bug is that I use "Enter" to jump back out of copy mode and to the bottom of the terminal, but that now submits the current prompt, which has caused me to accept code suggestions I wasn't ready to accept.

Incidentally, the labels here say "platform:linux" but this also affects mac.

[RobBiddle]

Came here to open this as an issue, but searched first 😎

I'm trying to use tmux or abduco within the VS Code terminal in a Codespaces environment.
Here's Claude's description of what I've found:

Version: Claude Code 2.1.150, Node 22.22.3, Debian-based devcontainer in GitHub Codespaces

Reproduction matrix:

Wrapper | VS Code terminal | Windows Terminal via gh codespace ssh -- | -- | -- None (direct claude) | Classic renderer ✓ | Classic renderer ✓ abduco | Fullscreen renderer ✗ | Fullscreen renderer ✗ tmux | Fullscreen renderer ✗ | (not retested, same as VS Code expected)

All cells set CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 in claude's environment.

Verified:

• The env var reaches claude's process inside abduco (echo $CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN → 1 in an abduco-attached shell)
• Node's TTY view of the terminal is identical between direct and wrapped invocations: {stdoutTTY: true, stderrTTY: true, cols: 203, rows: 49, colorDepth: 24}
• Process environment is identical between cases (diff'd: only SHLVL differs)
• Same behavior whether claude is exec'd directly by abduco or launched from a shell inside the abduco session

Expected: Per the v2.1.132 changelog and fullscreen docs, this env var should force the classic renderer regardless of other conditions.

Actual: Claude Code overrides the env var when invoked through any pty wrapper, regardless of terminal emulator. Likely an internal capability-probe path that takes precedence over the explicit override.

Impact: No working configuration for using Claude Code's classic renderer (native scrollback) inside a detach-style session manager. Forces users to choose between process persistence (lose scrollback) or native scrollback (lose persistence).

Suggested fix: When CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 is set, skip any capability-based auto-promotion to fullscreen — let the env var be a hard override as documented.

[tgockel]

Workaround for some of the issues is reverting the TUI from the now-default "fullscreen rendering" mode and back to the "default" TUI. The documentation currently notes "Fullscreen rendering is an opt-in research preview," but it seems like that isn't really the case. You can opt-out in ~/.claude/settings.json:

{
  "tui": "default"
}

Try this live with /tui default.

Make sure you don't have the environment variable CLAUDE_CODE_NO_FLICKER=1, as that will bring you into fullscreen mode no matter what your settings file says. The CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN appears to have no effect at all no matter what.