[BUG] Fullscreen TUI: mouse wheel is a complete no-op on native Windows across multiple terminals

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Aug 11, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

With Claude Code using the fullscreen TUI renderer ("tui": "fullscreen"), mouse-wheel scrolling is completely non-functional on native Windows.

The wheel produces no visible movement or other reaction.

I reproduced the same failure in multiple unrelated terminal environments:

  • Windows Terminal + PowerShell 7
  • standalone PowerShell 7
  • standalone cmd.exe
  • Rio + PowerShell 7

Normal terminal scrollback works in all of these environments when Claude Code is not using the fullscreen TUI.

The strongest isolation test is changing only the Claude Code renderer:

/tui fullscreen  -> mouse wheel does nothing
/tui default     -> mouse wheel works
/tui fullscreen  -> mouse wheel does nothing

No terminal, shell, Windows, or mouse configuration changes between those states.

No Claude Code mouse/scroll override environment variables are set.

This appears to be specific to Claude Code's fullscreen rendering/input path on native Windows rather than a terminal-specific scrollback problem.

What Should Happen?

When tui: "fullscreen" is active, mouse-wheel input should scroll Claude Code's fullscreen/virtualized conversation history.

If fullscreen wheel handling is unavailable in a particular Windows terminal environment, Claude Code should fall back gracefully instead of leaving the user with no working mouse-wheel scroll path.

Error Messages/Logs

No error message is shown.

The mouse wheel is simply a no-op while `tui: "fullscreen"` is active.

### Error Messages/Logs

```shell

Steps to Reproduce

  1. Use native Windows 11 with Claude Code 2.1.220.
  1. Confirm the stable build is current:

``text
> claude update
Current version: 2.1.220
Checking for updates to stable version...
Claude Code is up to date (2.1.220)
``

  1. Ensure none of these variables are set:

``text
CLAUDE_CODE_DISABLE_MOUSE
CLAUDE_CODE_DISABLE_MOUSE_CLICKS
CLAUDE_CODE_DISABLE_VIRTUAL_SCROLL
CLAUDE_CODE_SCROLL_SPEED
CLAUDE_CODE_NO_FLICKER
CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN
``

  1. Start Claude Code and enable fullscreen rendering:

``text
/tui fullscreen
``

Equivalent setting:

``json
{
"tui": "fullscreen"
}
``

  1. Generate enough conversation history to require scrolling.
  1. Rotate the mouse wheel.

Actual: nothing happens. The conversation does not move and the wheel produces no other visible reaction.

  1. Repeat in other native-Windows terminal environments.

Reproduced in:

  • Windows Terminal + PowerShell 7
  • standalone PowerShell 7
  • standalone cmd.exe
  • Rio + PowerShell 7
  1. As a terminal-control test, exit Claude Code and generate ordinary shell scrollback.

PowerShell:

``powershell
1..5000 | ForEach-Object {
"Line $_ - Scrollback test - ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789"
}
``

cmd.exe:

``cmd
for /L %i in (1,1,5000) do @echo Line %i - Scrollback test - ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789
``

Result: native mouse-wheel scrolling works normally.

  1. Start Claude Code again and run:

``text
/tui default
``

  1. Repeat the scrolling test.

Result: mouse-wheel scrolling works normally.

  1. Run:

``text
/tui fullscreen
``

  1. Repeat the scrolling test.

Result: mouse-wheel scrolling is a no-op again.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.220 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Terminal/Shell

Windows Terminal

The same issue also reproduces in:

  • PowerShell 7 in a standalone console
  • cmd.exe in a standalone console
  • Rio + PowerShell 7

Additional Information

Confirmed workaround

Switch to the classic/default renderer:

/tui default

This persists:

"tui": "default"

in ~/.claude/settings.json.

The equivalent environment-variable workaround is:

CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1

Renderer A/B isolation

This is consistently reproducible:

/tui fullscreen  -> wheel no-op
/tui default     -> wheel works
/tui fullscreen  -> wheel no-op

This is the strongest evidence that the failure is tied to Claude Code's fullscreen renderer/input handling.

Configuration ruled out

The following were checked and are not responsible for the failure:

  • Claude Code mouse/scroll override environment variables
  • PowerShell profile customizations
  • competing Claude Code user/managed settings overriding tui
  • terminal scrollback capacity/settings
  • conhost QuickEdit as a general explanation, because the failure also reproduces in Windows Terminal and Rio

Scope of the root-cause claim

Changing only tui from "fullscreen" to "default" fixes the issue.

The exact internal point where fullscreen wheel events are lost has not been determined. I have not captured the live mouse escape-sequence/event stream, so I am not claiming a specific protocol-level failure.

Related issues

Related reports exist, but they describe different symptoms or triggers:

  • #82886 — fullscreen mouse/text-selection behavior on Windows
  • #72215 — fullscreen scrolling inaccessible, including keyboard scrolling
  • #70724 — CLAUDE_CODE_DISABLE_MOUSE=1 causes wheel input to navigate prompt history
  • #65833 — wheel input translated to arrow keys
  • #80033 — fullscreen scroll stutter/performance regression

This report is specifically about fullscreen mode with no mouse opt-out variables set, where wheel input is a complete no-op across multiple native-Windows terminal hosts.

View original on GitHub ↗