[Bug]: Terminal still scrolls to top after Claude output

[PeaceRebels]

Current Behavior

When using Claude Code and when Claude asks for input (or sometimes randomly), the Wave Terminal will automatically scroll all the way to the top and user has to manually scroll down. I saw another issue describing the same already open since October 2nd. Unfortunately makes Wave Terminal almost unusable for Claude Code users.

Expected Behavior

Doesn't scroll up.

Steps To Reproduce

1. Use a Terminal inside Wave to use Claude Code

Wave Version

0.13.1

Platform

macOS

OS Version/Distribution

Tahoe 26.2

Architecture

arm64

Anything else?

No response

Questionnaire

• I'm interested in fixing this myself but don't know where to start
• I would like to fix and I have a solution
• I don't have time to fix this right now, but maybe later

[caoccao]

I met the same issue. Now I have to abandon wave when using Claude Code.

[erikaflowers]

I have the same issue.

[mackh]

glad its not just me, on a mac, hit shift + down arrow to jump to the bottom

[Oceanswave]

sadly using another terminal until this gets resolved.

[sawka]

Sorry about this, it sounds super frustrating. Been working on some potential fixes #2941 and #2944, but the big problem is I just can't seem to reproduce the issue on my mac or on my windows box. I believe it is happening since there are so many bug reports, but I'm really struggling to figure out what is causing it (been pouring through the Wave and xterm.js code looking for anything that would cause a scroll to top).

(also reference the duplicate bug #2384 )

If anyone else has this bug please include what platform (macos, windows, linux) you are on. If on mac also please let me know if you have automatic or always for "show scroll bars", and if you are on Sequoia or Tahoe.

Also, are you seeing this when:

• Switching Tabs
• Resizing the Terminal / Window
• When Claude Code asks for input
• When pasting input into Claude Code
• Sometime else?

The more specific with the "when" can maybe help me narrow it down or repro it. Thanks

[sawka]

Linking the CC issue here as well -- anthropics/claude-code#826
I wonder why certain people and certain terminals are having more problems.

[caoccao]

Hi @sawka , it usually happens when CC clears the terminal after an auto-compact context.

[sawka]

I put a lot of instrumentation into wave and a custom built xterm.js instance. I finally understand what is going on (for the most part).

Underlying issue is that on terminal resize (or i guess auto-compact) CC will emit a CSI 3 J escape code which means clear the terminal and the scrollback. it then repaints the entire session. The timing can be weird. Sometimes that happens almost instantaneously, but if it is "thinking" there can be a larger delay (tens of ms). When it clears everything, scrollTop obviously gets set back to 0. Now it doesn't always pin to the top, because there are heuristics, especially around "if you were at the bottom of the terminal, and new output arrives, try to stay at the bottom". But even those, completely fail when the terminal is "scrolled up" a bit which can easily happen when a resize happens while output is flowing in. I have also not tracked down a specific escape sequence or signal that I can use to know when the repaint is done (if I knew this I could just restore the line back after seeing that -- although the compaction screws with that).

I still need to track down why asking for input sometimes triggers this (maybe it is the auto-compact running at that time?).

While I don't think this issue can be 100% fixed, now that I know what's going on I can do a lot of mitigation.

I've already enhanced the scroll-to-bottom detection. I might also put the terminal into a special "CC" mode when I detect that CC is running so I can enforce stronger rules that match CCs output patterns (specifically when I see this CSI 3 J escape code).

CC to #2384

tl;dr now that I know what's causing a lot of the CC jumpiness I can fix the bulk of the problem