Claude in iTerm2 will unpredictably scroll through the entire shell stdout history while executing commands

Something similar in default terminal on a Chromebook. I have to hit space bar or some other hopefully harmless key to snap it back into current state...

When you say "scroll through the entire shell stdout history", do you mean Claude Code's entire history from the start of this session?

It's hard to know for sure, but yes, it seems like that - it's a very rapid display of output on the screen, too fast to read, but it does seem roughly about as long as the history during that session.

Update: It seems like it may start when a user inputs a prompt past a certain number of newlines.

I think i've seen this same behavior. And if I compact then I can still compact again when in this state and sometimes even again

Same here with powershell 7.5.0

Sometimes, it seems like the content of Claude console tries to "instantly refresh to add content" but that triggers some fast scrolling from the beginning to the end. Just like when console software tries to quickly flush and rewrite the content (with some modifications) to give the illusion of interactive content, but rewriting takes too many seconds.

When that happens and there is a multiple choice (yes; yes and don't ask again for this session; no and tell Claude what to do instead), pressing the down arrow key to change answer, also triggers that fast "redraw-scrolling".

Same here using conemu with a WSL shell. It works great, but insists on starting at the top of the content for this session and scrolling down again.

Although - I have just migrated from a global install to local, and it seems to have stopped. Not sure whether that was coincidence, but might be worth trying?

EDIT: That didn't fix it

Same problem

same problem with iterm2 + zsh on mac, after a couple of messages claude code starts to reset to the start of the shell history and rapidly scroll the entire length, then starts looping on that on every message it does after a certain point, forcing a terminal kill (cmd + c, space, enter, etc.. workarounds work sometimes but rarely)

to somewhat mitigate this you can scroll your view all the way to the bottom and press enter. it will still do a quick scroll around but it'll be super quick vs long scroll loops

<img width="101" alt="Image" src="https://github.com/user-attachments/assets/39eaf6d2-4719-46b2-9c57-102311eba24b" />

I can confirm, I'm experiencing this. It definitely has something to do with long history. If you work in a long session and run multiple /clear commands, it will happen eventually. I've tried closing CC and clearing the terminal history, setting different history line limits 1000, infinite in my iTerm. Nothing stops this from happening eventually.

same

Same. My use case is ssh from a mobile device into a tmux session, and I regularly have to sit through two or three minutes of intense (and eye bleeding) buffer re-scrolling - in a session length of 2days + the chances seem to be approaching 100% that this will become irrecoverable and I have to kill the tmux session and start over.

same, on wsl bash terminal in vscode, i call it 'cc scroll of death' - also happens in Gemini CLI, first one to tackle this will definitely get a bonus, come on, you guys! this is a bummer, happens all the time context window is large enough to require much scrolling..

Also facing this; I believe it's related to copy-pasting logs etc into claude code.

If you don't need it, clear scrollback buffer under the edit menu in iTerm makes life easier.

Getting this in Ubuntu GNOME terminal too. And the vscode terminal. And in IntelliJ IDEA. whatever terminal control library Claude is using sometimes gets into a state and then everything goes disco mode. Currently every time I switch terminal back to claude I get this:

https://github.com/user-attachments/assets/8d6dbc65-3290-45f5-b345-7d76c5303055

Apparently duplicate or related issues: #769 #1486 #1854 #2761

Would be lovely to fix this, or else put a warning about strobe effects (!)

(edit: the screencap didn't work as well as I'd like, in reality you see it redrawing apparently from the beginning of history about three times before it settles down. I only "switched tabs" here, I pressed no other key)

I see this issue on MacOS 15.6.1 using tmux in kitty, but not without tmux in kitty.

Same here. iTerm 2 latest macOS

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This is happening to me too on iTerm2 on a MacBook Pro running Sonoma 14.7.6

Still happens to me in the latest version

Same for me using tmux in iterm2

Same in iterm2. Imho it's something with plan mode, I didn't see this problem in any other mode.

Happens so much in iTerm2, making the tool barely usable. Can't monitor what Claude is doing, really have to "feel the singularity" or whatever. Gets worse if you have a long-running session w/ multiple compacts.

Happening to me too. it's really annoying and causes iterm2 to crash because its just constantly and recursively filling up the history with stuff that's already there. Also means search is unusable

I am still looking for an option in iTerm2 that it doesnt scroll wildly whenever new input it coming to the terminal but at least stays at the current scroll position. Anyone?

+1 — Also happens on Linux (Bash, Fedora 42)

Date: 2026-03-01 — Issue still not resolved.

Same behavior observed: unpredictable scrolling through shell stdout history while Claude executes commands. Happens intermittently, no clear pattern.

Band-aid workaround:

Option 1: Press Page Down or End key to jump back to the last line when scrolling occurs.

Option 2: Add this to your shell config (~/.bashrc or ~/.zshrc) to auto-jump to bottom after each command:

# Auto-scroll to bottom after command output (Linux)
PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND; }echo -ne '\e[999B'"

Or for zsh:

# Auto-scroll to bottom (Linux)
precmd() { echo -ne '\e[999B' }

Note: I am on Linux and these workarounds work there. Portability to macOS/Windows is not assured.

These are just band-aids — the underlying issue persists. Would be good to have this properly fixed.

This still happens.

Would love to see this fixed! 🙏🏻

Experiencing this daily on iTerm2 with tmux -CC integration mode over SSH. The scroll-to-top behavior makes it impossible to review Claude's output while it's streaming. Gets worse as the conversation grows. Using /compact and /clear are workarounds but the core issue — full TUI redraws resetting scroll position — needs a fix. This is one of the biggest friction points for remote Claude Code usage.

我也遇到了，我开始用的tabby，以为是tabby的问题，后来换成了iterm2，发现也有同样的问题，只不过是概率的问题，有的时候换个窗口或者重启一下就好了。有的时候每次对话他都会给我滚动到很久之前的聊天记录那里，需要我按下空格或者输入任意东西才会滚动回到地步，这确实需要优化一下

also met this kind of issue. Is there any plan to fix it?

This scrolling issue is part of a broader pattern (#826, #769, #1486, #367, #33814) where Claude Code's TUI rendering causes unintended scroll behavior.
Workaround 1 — tmux isolates scrolling:

tmux new-session -s claude 'claude'

tmux manages its own viewport independently of the terminal's scroll buffer. Scroll with Ctrl+B [ in tmux instead of using the terminal's native scroll.
Workaround 2 — Compact to reduce rendered history:

/compact

Less conversation history = less content to render = less scrolling issues. Compact at natural breakpoints.
Workaround 3 — Reduce terminal scrollback:

• iTerm2: Preferences → Profiles → Terminal → reduce "Scrollback lines" (try 1000)
• Windows Terminal: Profile → Advanced → History size → reduce

Smaller scrollback buffers reduce the range of scroll-jumping.
Workaround 4 — Fresh sessions for new tasks:

claude  # Start fresh instead of continuing long sessions

Workaround 5 — Use headless mode for non-interactive work:

claude -p "your task" > output.md

No TUI = no scrolling issues.