Not disagreeing but scrolling works just fine in vim/emacs/etc. Wouldn't it be just managing the scroll back buffer yourself rather than the terminals?
With the usual terminal mode, that history can outlive the Claude application, and considering many people keep their terminals running for days or sometimes even weeks at a time, that means having the convo in your scrollback buffer for a while.
You should be able to find it in ~/.claude
You can also ask Claude to search your history to answer questions about it.
Their hypothesis was that maybe there was aj intention to have claude code fill the terminal history. And using potentially harzardous cursor manipulation.
In other words, readline vs ncurse.
I don't see python and ipython readline struggling as bad tho...
When I scroll up in nvim, it will keep the editor frame in place (that's the top bar and bottom bar showing things like open buffers, git status, the scratch buffer or whatever it's called), but the file contents will scroll by because nvim at that point has exclusive ownership of the entire screen and can do anything with it, including repainting parts of it in response to motions or a mouse scrolling (if your terminal supports emitting mouse events).
This is in contrast to the `rmcup` "normal" terminal mode where it will scroll back in the terminal's history.
The best analogue I have for that last one is to use tmux with nvim open, and have a tmux visual selection going. You can scroll up and out of nvim, and keep scrolling to whatever was executed before neovim, and when you get out of tmux visual mode it'll snap back down to the bottom of your scrollback buffer, nvim (nominally) taking up the entire pane like nothing happened; but we can probably agree that outside of a few narrow use cases, this isn't a very desirable way to manage scrolling in a terminal.