Yes, but this does come with differences and tradeoffs. If the terminal isn't managing the scrollback, you don't get scrollbars and you lose any smooth/high resolution scrolling. You also lose fancy terminal features like searching the scrollback, all that needs to be implemented in your application. Depending on the environment it can also wind up being quite unpleasant to use with a trackpad, sometimes skipping around wildly for small movements.

I think they were saying that in "cup" screen mode (CUP: CUrsor Position, activated with smcup termcap), when you exit (rmcup) the text is lost, as well as the history since it was managed by the application, not the terminal.

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...

To clarify: this is the terminal's scrollback buffer vs one managed by the application in the alternate screen.

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.

That conversation should still exist in the Claude Code log files. Just give Claude some context on how to find it, and it will pull whatever you need. I use this to recall particularly effective prompts later on for reuse.

Can confirm (used to work in the games industry). Code reviews and automatic testing of any kind are a rare sight.

In my experience games crash a lot less often than the windows file explorer

I feel like we give what’s some pretty impressive engineering short shrift because it’s just for entertainment

I've had it do it occasionally in all of Ghostty, iTerm2 and Prompt 3 (via SSH, not sure what terminal emulator that uses under the hood)

I thought I was the only one who had this problem - so annoying, and the frequent Ui glitches when it asks you to choose an option .

Wow I thought it was tmux messing up on me, interesting to hear it happens without it too

Scrolling around when claude is "typing" makes it jump to the top