Mouse scroll cycles through input history in Android Studio's integrated terminal

[kavin-s-18660]

scroll_issue.mov

Describe the bug

Since upgrading to Copilot CLI v1.0.43, mouse scroll wheel events in Android Studio's integrated terminal are being interpreted as Up/Down arrow key inputs, causing
the input prompt to cycle through previous commands instead of scrolling the terminal buffer. This does not occur in macOS Terminal.app or other standalone terminals.

Environment:

• Terminal: Android Studio integrated terminal
• OS: macOS

Affected version

v1.0.43

Steps to reproduce the behavior

1. Open Android Studio's integrated terminal
2. Launch copilot
3. Enter a few prompts
4. Scroll up/down with mouse wheel

Expected behavior

Instead of scrolling terminal, it's filling previous prompts I've given

Additional context

No response

[akafred]

Same bug in a different embedded terminal (Electron + xterm.js), with the root cause
traced. Copilot CLI 1.0.82, macOS arm64.

Copilot CLI arms mouse tracking exactly once, at startup, and never re-asserts it.

Captured from a bare pty, no embedding involved:

ESC[>4;2m  ESC[?u  ESC[?2026$p  ESC[?1049h  ESC[?2004h  ESC[?1004h  ESC[?1003h  ESC[?1006h  ESC[?25l

Afterwards, nothing re-arms it:

stimulus	mode traffic emitted
SIGWINCH resize	ESC[?7l, ESC[?7h only
focus-in (ESC[I)	none
typing	none

Repro:

import os, pty, time, re, fcntl, termios, struct
pid, fd = pty.fork()
if pid == 0:
    os.environ['TERM'] = 'xterm-256color'
    os.execvp('copilot', ['copilot'])
fcntl.ioctl(fd, termios.TIOCSWINSZ, struct.pack('HHHH', 40, 120, 0, 0))
os.set_blocking(fd, False)
pat = re.compile(rb'\x1b\[\?[0-9;]+[hl]')
def pump(sec, label):
    t, b = time.time(), b''
    while time.time() - t < sec:
        try:
            d = os.read(fd, 65536)
            if d: b += d
        except Exception: pass
        time.sleep(0.03)
    print(label, sorted({m.decode('latin1').replace('\x1b', 'ESC') for m in pat.findall(b)}))
pump(5, 'startup')
fcntl.ioctl(fd, termios.TIOCSWINSZ, struct.pack('HHHH', 30, 100, 0, 0))
pump(3, 'after-resize')

Why that turns into history scrubbing. Any terminal that is attached to the pty
after that one-shot burst — or whose emulator state is rebuilt from a snapshot, which
is what embedded terminals do on reattach — sees ?1049h (alternate buffer) but no
mouse tracking. That combination is exactly the classic alt-screen scroll fallback:
xterm.js does it in _handlePassiveWheel, and other embedded emulators implement the
same convention.

if (!e.requestedEvents.wheel) {
  if (!this._bufferService.buffer.hasScrollback) {        // alt buffer
    const e = ESC + (applicationCursorKeys ? "O" : "[") + (deltaY < 0 ? "A" : "B");

The wheel is therefore delivered to Copilot CLI as ESC[A / ESC[B, which Copilot CLI
binds to prompt history — matching the video in this issue exactly. Standalone terminals
are unaffected because they saw the startup burst live and keep forwarding SGR reports.

Corroboration: quitting Copilot CLI and resuming it in the same pane fixes it for
that session, because the fresh startup burst reaches a live, attached emulator. Nothing
else recovers it — resizing does not, refocusing does not.

Suggested fix: re-assert ESC[?1003h and ESC[?1006h (alongside ?1049h,
?2004h, ?1004h) on SIGWINCH and on focus-in. Copilot CLI already enables focus
reporting with ?1004h, so it receives focus-in events and could re-arm from a handler
it mostly has already. Re-asserting on repaint would be even more robust. As it stands,
a single missed burst degrades the wheel into destructive input for the rest of the
session, with no in-app recovery.

For contrast, Claude Code 2.1.247 avoids this class entirely by not using the alternate
buffer and not arming mouse tracking at all, so the wheel remains ordinary terminal
scrollback.

[dong-brian]

[bot] Additional reproduction: cmux on macOS

I can reproduce this in cmux, not only Android Studio's integrated terminal.

Environment

• macOS 26.6.2 (25G83), arm64
• cmux 0.64.22 (102)
• Copilot CLI 1.0.82
• TERM=xterm-256color
• TERM_PROGRAM=ghostty
• TERM_PROGRAM_VERSION=1.3.2-HEAD-+6143bac
• Shell: bash

Steps to reproduce

1. Open cmux and create a new terminal tab or workspace.
2. Run copilot.
3. Submit enough prompts to populate input history and generate scrollable output.
4. Scroll up or down with the mouse wheel or trackpad.

Actual behavior

The wheel is interpreted as Up/Down input. Copilot cycles through previous prompt history instead of scrolling the terminal output or conversation transcript.

Expected behavior

Mouse-wheel and trackpad scrolling should scroll the Copilot output/transcript without changing the current input.

Confirmed version comparison

• Fresh cmux tabs running Copilot CLI 1.0.82 reproduce the issue.
• Older cmux tabs on the same machine running Copilot CLI 1.0.80 behave correctly.
• I launched a fresh cmux workspace using Copilot CLI 1.0.80 directly; scrolling worked correctly there.
• Standalone terminal usage does not show the problem.

I also tried setting "mouse": false in ~/.copilot/settings.json, but the problem persisted in cmux. Setting Ghostty's mouse-reporting = false stopped the input-history behavior but also made cmux output scrollback unusable.

This makes the 1.0.80 versus 1.0.82 version boundary reproducible on the same cmux installation and strongly suggests a Copilot CLI 1.0.82 regression involving embedded-terminal or alternate-screen mouse-mode initialization.

[stefan-markovic-rbrs]

Additional reproduction: Windows Terminal + WSL2

I can reproduce this issue with Copilot CLI 1.0.82 in Windows Terminal running WSL2.

Environment

• Copilot CLI: 1.0.82
• Terminal: Windows Terminal
• Environment: WSL2
• Distribution: Fedora Linux 44
• Kernel: Linux 6.18.33.2-microsoft-standard-WSL2
• Architecture: x86_64
• TERM=xterm-256color

Actual behavior

Using the mouse wheel cycles through previously submitted prompts instead of scrolling the conversation timeline. The Up and Down arrow keys produce the same behavior.

The timeline can only be scrolled using Shift+PageUp and Shift+PageDown.

Expected behavior

The mouse wheel should scroll the Copilot conversation timeline without modifying or cycling through the prompt history.

Version comparison

This started after upgrading to Copilot CLI  1.0.82 . The behavior matches the alternate-screen mouse initialization regression described in this issue.