[BUG] Mouse tracking not disabled when Claude Code is suspended with Ctrl-Z

Confirming this on a completely different terminal + shell, which supports your hunch that it isn't xfce4-terminal-specific:

• Terminal: kitty
• Shell: zsh with atuin

Same failure, different surface symptom: after suspending Claude Code with Ctrl-Z, a touchpad/wheel scroll pops open atuin's history search instead of scrolling kitty's scrollback. atuin binds the Up arrow, which is the tell for the underlying mechanism.

Mechanism: while running, Claude Code enables mouse/scroll reporting (and leaves alternate-scroll behaviour on). With that mode still active, kitty stops treating a wheel event as "scroll the scrollback" and instead forwards it to the foreground program as cursor-key input (scroll up → Up, scroll down → Down). Those arrows land in zle, and atuin's Up binding catches them — exactly the same class of bug as bash cycling its command history in the original report.

Why a clean exit is fine but Ctrl-Z isn't: quitting Claude normally runs its terminal-restore path, which sends the reset sequences and hands scrollback back to the terminal. Ctrl-Z raises SIGTSTP and stops the process immediately, so that restore never runs and the modes are left enabled. This is the specific case of the more general #78690 (TUI doesn't restore terminal state on SIGTSTP) — a SIGTSTP/SIGCONT handler that saves and restores terminal modes would fix both.

Userland workaround (zsh) — zsh runs precmd hooks when it regains control after a suspend, so re-disabling the modes there heals the terminal the moment you land back at the prompt. Harmless at a normal prompt, and a real Up keypress still opens atuin:

autoload -Uz add-zsh-hook
_reset_terminal_input_modes() {
  # 1000/1002/1003 mouse tracking, 1006 SGR extended, 1007 alternate scroll
  printf '\033[?1000l\033[?1002l\033[?1003l\033[?1006l\033[?1007l'
}
add-zsh-hook precmd _reset_terminal_input_modes

Version: Claude Code 2.x, macOS.

Still present in 2.1.228 (reported here against 2.1.210), on a different platform and without CLAUDE_CODE_DISABLE_MOUSE_CLICKS set:

• Claude Code 2.1.228
• WSL2 (Linux 6.x microsoft-standard-WSL2), Windows Terminal, zsh
• "tui": "fullscreen" in settings.json
• CLAUDE_CODE_DISABLE_MOUSE_CLICKS not set

Same symptom: after Ctrl+Z, the scroll wheel cycles zsh history instead of scrolling scrollback. Persists for the life of that terminal; a new terminal is unaffected; reset clears it.

So this isn't specific to xfce4-terminal or to CLAUDE_CODE_DISABLE_MOUSE_CLICKS.

Worth noting that exiting Claude Code normally restores the terminal correctly — the teardown path works, it just isn't wired to the suspend path.

Thanks for the detailed repro — confirmed on 2.1.233 (Linux).

One correction to the mechanism: capturing the terminal output during Ctrl-Z shows Claude Code does disable mouse tracking (and focus reporting, bracketed paste) right before suspending, and re-enables it on fg — on both 2.1.210 and 2.1.233. What it doesn't do is leave the fullscreen alternate screen, so your shell prompt lands inside it while Claude Code is suspended. In VTE-based terminals like xfce4-terminal, scrolling the wheel in the alternate screen sends Up/Down arrow keys — which is exactly why bash cycles through history instead of the terminal scrolling back, and why your earlier ls -R output is unreachable.

So: confirmed bug, just with a different cause than the title suggests — suspend should also leave the alternate screen and re-enter it on resume (like vim/less do). Reproduced consistently on 2.1.233.

Workaround in the meantime: launch with CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 to use the native-scrollback renderer, which avoids this entirely.

🤖 Generated with Claude Code