Claude Code odd scrollback behavior on window resize

[lucasec]

I've been chasing weird quirks with Claude Code's tendency to aggressively rewrite the scrollback across multiple terminal emulators in Emacs. Every emulator seems to have its own quirks and a few packages such as claude-code-ide have taken it a step further and implemented their own render batching and other patches to try to improve the behavior.

It seems like a lot of these problems should be resolved by ghostel implementing DEC 2026 Synchronized Output, and I am finding that ghostel generally has less re-draw quirks than vterm and eat. However, it's not zero, as can be seen by this brief demonstration of popping open the minibuffer:

Untitled.mp4

Interestingly, typing text at any point during the scrolling animation causes the terminal to immediately jump to the end with the scrollback seemingly fully in tact.

Note that I was seeing this behavior even on version of ghostel prior to #73.

To test, I have been resuming a ~4 MB claude code session and then cycling between the normal and detailed transcript modes with C-o + C-e, popping open the minibuffer (I use ivy + counsel-M-x for completion), and resizing the Emacs frame.

Newer versions of Claude (after Anthropic launched their alternative-frame-mode "no flicker" feature) seem to be buggy about re-writing the scrollback in the classic mode (often they will leave the scrollback buffer half rewritten, and this issue seems to affect all terminal emulators), so I tested by backdating with claude install 2.1.87 followed by DISABLE_AUTOUPDATER=1 claude --resume.

[dakra]

Thank you very much for the detailed report ❤️

I saw the same. At some point I had some fancy debounce tricks to make it appear better but removed it as it was not too bad and only a claude-code problem. The DEC 2026 hint might be very helpful.
I'll investigate. Thanks.

Note that I was seeing this behavior even on version of ghostel prior to #73

That's good to know. Because #73 was a bigger rewrite and could break some things.
I tested it for a few days and didn't notice anything, but how the scrollback is now written is completely different
so I'm almost assuming something is going to break. (Let me know if you find something)

Newer versions of Claude (after Anthropic launched their alternative-frame-mode "no flicker" feature) seem to be buggy

Honestly claude-code is annoying me more and more.
Half the time I'm not sure if something is broken in ghostel or if it's just yet another bug in claude-code.
They think it's a flex that they vibe-code everything and ship so many features while their software
is super buggy and if you look at the changelog, 70% of the entries start with "Fix ...".
/rant over ;)

[dakra]

Can you try with the latest commit (needs a new native module build/download). I think I fixed it.
The problem had actually nothing to do with DEC2026 which we already respect,
but on a resize I prematurely erased the whole buffer so libghostty could do the reflow.
That caused the viewport jump and the flickering behaviour.
On my quick tests it works nicely now.

I'll not close this issue yet and wait for your comment/test.

[lucasec]

It looks better but I still managed to produce the behavior after a bit. I had to resize the window width once, then it seems to happen again every time I opened and closed the minibuffer (tested both on Claude 2.1.87 and 2.1.104)

For what it's worth, I just finished re-factoring Eat to support DEC 2026. If you want a quick comparison, you can check out my branch here: https://codeberg.org/lucasec/emacs-eat/src/branch/synchronized-output
My finding is that adding DEC 2026 to Eat made almost all the Claude glitches go away, but I probably need to run it through your benchmark to see how much performance overhead my implementation added.
The one Claude annoyance that was not solved by adding DEC 2026 is that if you are currently reading through the scrollback when Claude decides to re-write it, you will almost certainly lose your current viewport and cursor position (some further hacks to try to fix that).

[dakra]

Strange. What OS and Computer are you using?
Currently I'm on a Mac M4 which is pretty fast, maybe that's why I can't reproduce it?
I tried a few different variations and it always works pretty nicely.

BTW, I plan to finish the different eat modes implementation in ghostel this week,
then imho you only need eshell and ghostel as ghostel has all features from vterm and eat (plus a lot more).

[lucasec]

I'm using a MacBook Pro with M1 Pro, so it should be comparable.

I just pulled the latest branch and tested again, and sure enough still seeing the rapid scrolling:
https://drive.google.com/open?id=1VFVtL6vIssF30jsnhVQp8cK8nL7NtfE2&usp=drive_fs (using a Google link since GitHub has a size limit). I can still trigger this any time I resize either the width or height of the ghostel window.

There is also some rapid screen flicker after I enter/exit the the detailed transcript view and then input some character into the prompt box.

No idea what is different between our setups. I also tested on a clean emacs --no-init with only ghostel loaded, so it doesn't seem like it's an interaction with another package in my setup. Btw I'm running Emacs 30.2, using the emacs-plus Homebrew formula.

[dakra]

I added some ghostel-debug commands to investigate further.

Can you first paste the output of ghostel-debug-info (inside the ghostel buffer)
and then do M-x ghostel-debug-start, reproduce the issue, M-x ghostel-debug-stop and paste this output as well (it's probably longer).

[lucasec]

ghostel-debug-info on new terminal:

=== ghostel-debug-info ===

--- System ---
Emacs version:       30.2
System type:         darwin
System config:       aarch64-apple-darwin25.2.0
Window system:       ns
Display pixel size:  1728x1117
Char size:           7x14 px
Native comp:         yes

--- Ghostel ---
Package version:     nil
Min module version:  0.14.0
Library path:        /Users/lucas/.emacs.d/elpa/ghostel-0.14.0/ghostel.elc
Module loaded:       yes
Module version:      0.14.0
Module file:         /Users/lucas/.emacs.d/elpa/ghostel-0.14.0/ghostel-module.dylib
Module size:         1381000 bytes
Module modified:     2026-04-16 01:11:58

--- Terminal State ---
Buffer:              *ghostel: Local*
Term rows:           32
Buffer size:         72 chars, 31 lines
Point:               43
Window body:         102x41 (cols x rows)
Window start:        1
Window end:          73
DEC 2026 (sync):     off
Force next redraw:   nil
Pending output:      0 chunks
Redraw timer:        none
Copy mode:           off

--- Settings ---
timer-delay:         0.033
full-redraw:         nil
adaptive-fps:        t
immediate-threshold: 256
immediate-interval:  0.05
scroll-conservatively: 101

The log file is pretty large, so attaching here:

ghostel-debug-log.txt

[lucasec]

Thanks for your interest in getting to the bottom of this btw. Meanwhile Anthropic's own rendering still seems to be full of bugs on the latest version.

BTW, I plan to finish the different eat modes implementation in ghostel this week,
then imho you only need eshell and ghostel as ghostel has all features from vterm and eat (plus a lot more).

I've been busy still putting hours into my Eat fork. Just finished up OSC 8 hyperlinks including an interesting little TAB navigation feature that might be nice to copy into ghostel.

Eat will probably still have its place, particularly for those that want a pure Elisp solution. There are some conveniences of Eat's architecture, e.g. scrollback doesn't occupy 2x memory having to be maintained in the native library's address space as well as the Emacs buffer (I realize your original architecture pre #73 didn't have that problem). Wrapping of long lines and reflowing those on window resize comes for free, etc.

Also, once you get the Eat modes, the next challenge will be to replicate Eat's eat-eshell minor mode ;)

[dakra]

Thanks for your interest in getting to the bottom of this btw.

Thank you for your patience. I didn't have a look at your logs yet but I just pushed a few changes
regarding (auto-)scrolling which makes the claude-code tui work for me a lot smoother.
Can you try again with the latest main branch commit?

Meanwhile Anthropic's own rendering still seems to be full of bugs on the latest version.

Yeah, it kinda annoys me that they play it like it's such a great thing that claude-code writes
all their code etc.. but their software (and der server apis etc) are all obviously really really
buggy and constantly break different things.
I could rant more but I stop ;)

Just finished up OSC 8 hyperlinks including an interesting little TAB navigation feature that might be nice to copy into ghostel.

Nice. That's super easy to implement and I'll put it on my todo.
Don't think I want to bind it to TAB though.. feel TAB in shell navigating to a url is confusing, no?

Eat will probably still have its place, particularly for those that want a pure Elisp solution

Maybe. But my goal is that you have eshell (just because it's different) and ghostel and that
satisfies all needs (besides maybe some minor niche things like you mentioned when you don't
want to load a native module or are restricted on memory or so)

Also, once you get the Eat modes, the next challenge will be to replicate Eat's eat-eshell minor mode ;)

what does that do exactly?
https://elpa.nongnu.org/nongnu-devel/doc/eat.html#Eshell-Terminal doesn't say too much.
What happens if I start e.g. vim in eat-eshell?

PS, slightly relevant, I recently added a ghostel-compile command that's just like normal compile
but with ghostel backend. Making that work with eshell-visual-commands should be easy as well.

[ynnebhc]

Thanks for your interest in getting to the bottom of this btw. Meanwhile Anthropic's own rendering still seems to be full of bugs on the latest version.

BTW, I plan to finish the different eat modes implementation in ghostel this week,
then imho you only need eshell and ghostel as ghostel has all features from vterm and eat (plus a lot more).

I've been busy still putting hours into my Eat fork. Just finished up OSC 8 hyperlinks including an interesting little TAB navigation feature that might be nice to copy into ghostel.

Eat will probably still have its place, particularly for those that want a pure Elisp solution. There are some conveniences of Eat's architecture, e.g. scrollback doesn't occupy 2x memory having to be maintained in the native library's address space as well as the Emacs buffer (I realize your original architecture pre #73 didn't have that problem). Wrapping of long lines and reflowing those on window resize comes for free, etc.

Also, once you get the Eat modes, the next challenge will be to replicate Eat's eat-eshell minor mode ;)

Off-topic here and sorry about this.

First many thanks for the work on EAT fork branch. I am wondering if you would like to check these bug fixes and see if they are good to be merged into your branch?

https://github.com/blahgeek/emacs-eat
https://codeberg.org/akib/emacs-eat/pulls/249

[dakra]

Just finished up OSC 8 hyperlinks including an interesting little TAB navigation feature that might be nice to copy into ghostel.

jFYI, I implemented ghostel-next/previous-hyperlink (C-c C-p/n) and also some eshell integration for eshell-visual-commands. See https://github.com/dakra/ghostel?tab=readme-ov-file#eshell-integration