[BUG] Semi-infinite scrolling in terminal

I have this problem, too.

what terminal emulator?

Same here in bash / VS Code terminal

bash/Cursor

I still have the problem using WSL in vs code but i believe i have used in just plain wsl and still gett he issue

This issue seems to be related to https://github.com/anthropics/claude-code/issues/769

I have the same issue. At seemingly random times, between 3 and 10 minutes of usage, a screen full of previous text would continue to scroll for seconds and sometimes minutes. There were times I was worried that all that text would cause the token usage to exceed some quotas, so I killed the process after scrolling for minutes. Restarting Claude Code didn't seem to help.

• Ghosty terminal
• macOS Silicon
• Max 200 plan
• Claude Code Status v1.0.43

Are you guys ever planning to fix this? It is a major drag on productivity and gives me a headache!

now I am getting this error after it happens:

node:events:502
      throw er; // Unhandled 'error' event
      ^

Error: write ENOBUFS
    at afterWriteDispatched (node:internal/stream_base_commons:159:15)
    at writevGeneric (node:internal/stream_base_commons:142:3)
    at Socket._writeGeneric (node:net:969:11)
    at Socket._writev (node:net:978:8)
    at doWrite (node:internal/streams/writable:596:12)
    at clearBuffer (node:internal/streams/writable:775:5)
    at onwrite (node:internal/streams/writable:653:7)
    at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:105:10)
Emitted 'error' event on WriteStream instance at:
    at emitErrorNT (node:internal/streams/destroy:170:8)
    at emitErrorCloseNT (node:internal/streams/destroy:129:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
  errno: -55,
  code: 'ENOBUFS',
  syscall: 'write'
}

Node.js v22.13.0

This is affecting me as well. Nothing new to add to the bug report, but I'm leaving a comment to add weight to the ticket.

This is affecting me as well.
I don’t have anything new to add to the bug report, but I’m leaving a comment to support the ticket.
I’m using Terminal and MCP Serena

I experienced this as well, then remembered that I had set my iTerm "Scrollback lines" setting to "unlimited scrollback".

I changed that to 5,000 lines instead, and I haven't experienced the issue since. Yes, I still get little blips where I see some very fast scrolling through terminal line history. But they only last a few seconds instead of multiple minutes.

My terminal is at 1,000 lines scroll back and I still have the issue.

There are a couple of ways to recreate this. The main way is if you paste a large block of text while it is thinking. This used to crash it all the time. I learned not to do this, so I don't know if this still works, but it was reliable before.

also happens in Claude Code in the Terminal in VSCode Remote from windows onto a Linux host with IDE integration enabled. I'm now trying a Claude app window in VSCode itself
Claude Code v1.0.98

This seems to be a terminal issue not a claude code issue. I have the same
issue with auggie-cli....

On Mon, Sep 1, 2025 at 1:40 AM M Lange @.***> wrote:

Shadyman left a comment (anthropics/claude-code#2118) <https://github.com/anthropics/claude-code/issues/2118#issuecomment-3240924154> also happens with VSCode Remote from windows onto linux. Claude Code v1.0.98 — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/2118#issuecomment-3240924154>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACTWE74OPYO6AL44FQZYKZD3QPL4DAVCNFSM6AAAAAB7LTBVUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENBQHEZDIMJVGQ> . You are receiving this because you authored the thread.Message ID: @.***>

It seems to trigger whenever Claude displays something that's larger than the working area of the chat portion of the screen (ie, not the text box, status line, etc.)

Large MCP executions, large summaries, etc, basically anything that scrolls off the end of the screen. It seems to want to re-scroll (re-draw?) every time a new line is output or a new key is pressed until it's done whatever it does during the scroll-fest.

I got the same issue

This is a HUGE ux impediment and needs urgent fix. I also find that keystrokes including ESC do not get registered while the infinite scrolling is ongoing

Doing CTRL + T or CTRL + O multiple times it fixes the problem but not everytime its better than nothing i guess

Everyone on my team has this problem. Any time the output is too long it seems that Claude goes nuts with scrolling until it prints the next thing. This happens all day long and it is a huge issue as I can't really type. I wouldn't be surprised if it could be medically dangerous for people who have strobe sensitivities.

I've seen this inside:

VSCode on Windows to Ubuntu
PuTTY on Windows to Ubuntu
KiTTY on Windows to Ubuntu

It has persisted since Claude 1.x all the way up to v2.0.21 (just updated tonight).

Bump. Also seems related to https://github.com/anthropics/claude-code/issues/826

This is a significant UX issue. The only "workaround" I've found is to frequently start new sessions (entirely close out Claude Code + start in fresh sessions with no previous context).

@bcherny @ThariqS @dhollman

This still isn't fixed.

i have to kick claude to background and restore it to fix this. happens any time i use the tmux scroll buffer. highly annoying

Bump. Also seems related to #826 This is a significant UX issue. The only "workaround" I've found is to frequently start new sessions (entirely close out Claude Code + start in fresh sessions with no previous context).

It's really annoying that this is still an issue. If you are looking for another workaround you can also try out https://github.com/davidbeesley/claude-chill which wrap claude code and prevents it from dumping output to the terminal.

Happens on roughly half of sessions that reach 80-130k tokens when in tmux or xterm.js. When in native iterm – did not reproduce. Can't find a common denominator for sessions that are impacted vs those that are not in terms of prompts, responses, project/files etc.

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.

Analysis

This issue has been open since June 2025 (v1.0.24) and still reproduces in current versions. The ENOBUFS error (write ENOBUFS, errno -55) confirms the root cause: the terminal output buffer overflows when the TUI renderer floods stdout faster than the terminal can consume it.

Why it still happens

The TUI renderer redraws the full terminal on every update. When the conversation history grows large (80k-130k+ tokens), each redraw outputs more data than the terminal's write buffer can handle. The buffer fills up → ENOBUFS → scroll jank or crash.

Plan mode makes it worse because it adds structured plan rendering on top of the conversation, increasing per-redraw output size.

Workarounds (from the thread)

| Workaround | How |
|---|---|
| Compact frequently | /compact reduces rendered history, shrinking each redraw |
| Use tmux | tmux new-session -s claude 'claude' — isolates scroll buffer |
| Reduce scrollback | Set terminal scrollback to 1000 lines max |
| Fresh sessions | Don't resume long sessions; start fresh per task |
| Headless mode | claude -p "task" > output.md — no TUI at all |
| Background/foreground | Ctrl+Z then fg to reset terminal state |
| claude-chill wrapper | https://github.com/davidbeesley/claude-chill — rate-limits output |

Fix needed (CLI internal)

1. Throttle TUI redraws — batch/dedup render calls so stdout never floods
2. Handle ENOBUFS gracefully — catch the error, back off, retry instead of crashing
3. Limit per-redraw output size — don't re-render the entire conversation; only render the delta since last frame