[Bug] Terminal auto-scrolls to bottom while Claude Code is working, preventing manual scroll

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/35512
2. https://github.com/anthropics/claude-code/issues/36128
3. https://github.com/anthropics/claude-code/issues/37366

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

+1 — same behavior on Ghostty (macOS). This is a duplicate of #33814 which has the most traction. The root cause is Ink's cursor-repositioning escape sequences on every TUI redraw. Terminal-side scroll settings can't fix it.

Workarounds: claude-chill (Rust PTY proxy with a lookback mode toggle) or running inside tmux.

👍 We're experiencing the same issue embedding xterm.js 6.0.0 in a Tauri app. The scroll position jumps when Claude Code redraws its TUI while the user is scrolled up. Confirmed root cause: cursor-up sequences exceeding viewport height + ESC[2J/ESC[3J.

:+1: Same issue with 2.1.81, in a VS Code terminal, MacOS host and running remotely on Ubuntu.

specifically when using hyprland (a tiling window manager/compositor), i have multiple windows open in the same desktop (in the top right corner quadrant for example), so being able to stop the auto scroll is more important

+1 — This also affects the submit action (pressing Enter), not just during generation. autoScrollEnabled: false in ~/.claude.json is ignored in the desktop app because the setting only works in fullscreen mode (/tui fullscreen). Users with long, structured conversations (I use letter-anchored points a-z, aa-zz) lose their scroll position every time they submit a message. The fix should respect autoScrollEnabled in all rendering modes, not just fullscreen. See #49183 for detailed report.

v2.1.153, Linux terminal (alacritty). The autoScrollEnabled knob (shipped recently) is binary, and neither setting matches the natural behavior:

• true: after the user scrolls up mid-stream, the view snaps back to the bottom once the message completes — defeating the scroll-up.
• false: the view never follows new output, even when it was already at the bottom on a fresh turn.

My, and others, mental model is tail -f / less +F / web-chat sticky-bottom:

1. Viewport at the bottom + new output arrives → follow.
2. User scrolls up at any time → release follow, stay where the user put it; do not re-acquire on message complete.
3. User scrolls back to the bottom → re-acquire follow.

Suggestestion: replace the boolean with autoScroll: "auto" | "always" | "never", default "auto". "always" preserves today's true, "never" preserves today's false, and the old boolean can map forward without breaking existing configs.