›_ Claude Code Issues
Claude Code Issues / #9001

Scroll regression in 2.0.8 - cannot scroll conversation history

Open 💬 21 comments Opened Oct 6, 2025 by johnsalamito

Bug Report: Scroll Regression in Claude Code 2.0.8

Issue Summary

Claude Code 2.0.8 has lost the ability to scroll through conversation history in terminal mode. Users can only view the last ~20 lines of responses, making long conversations impossible to review.

Versions Affected

  • ✅ 2.0.1: Scrolling works correctly
  • ❌ 2.0.8: Cannot scroll beyond visible viewport (~20 lines)
  • ⚠️ 2.0.5: Status unknown (likely affected)

Steps to Reproduce

  1. Start Claude Code 2.0.8: claude
  2. Have a conversation with responses longer than terminal height
  3. Try to scroll up to view earlier parts of the conversation
  4. Result: Cannot scroll beyond the last ~20 lines visible in terminal

Expected Behavior

Should be able to scroll through entire conversation history using:

  • Terminal scroll (mouse wheel, trackpad)
  • Shift+Page Up/Down
  • Terminal's native scroll functionality

This worked correctly in version 2.0.1.

Actual Behavior

Conversation output is locked to a fixed viewport showing only the most recent ~20 lines. Earlier content is inaccessible without using workarounds like:

  • claude --print "question" | less (bypasses interactive mode)
  • Ctrl+O transcript mode (workaround, not same as native scroll)

Environment

  • OS: macOS (Darwin 24.6.0)
  • Terminal: Terminal.app / iTerm2
  • Claude Code Version: 2.0.8
  • Install Method: npm global install

Root Cause Analysis

Likely introduced by this change in 2.0.8:

"Improve message rendering for users with light themes on dark terminals"

This rendering improvement appears to have inadvertently changed the output buffer behavior, locking responses to a fixed window instead of allowing terminal scroll.

Additional Context

  • This regression is not documented in release notes
  • No intentional deprecation of scroll was announced
  • Other Claude Code 2.0.x users have confirmed this issue
  • Workaround: Downgrade to 2.0.1 where scrolling works

Impact

High - Makes Claude Code unusable for:

  • Long debugging sessions
  • Code reviews with extensive output
  • Documentation review
  • Any conversation requiring reference to earlier responses

Proposed Fix

Restore scroll behavior from 2.0.1 while maintaining the 2.0.8 rendering improvements for light themes.

Reproduction Evidence

# Working version
$ npm install -g @anthropic-ai/claude-code@2.0.1
$ claude
# [Can scroll through full conversation history]

# Broken version
$ npm install -g @anthropic-ai/claude-code@2.0.8
$ claude
# [Cannot scroll beyond last ~20 lines]

---

Request: Please restore scroll functionality in next release or provide configuration option to enable scrolling.

View original on GitHub ↗

21 Comments

jleguina · 9 months ago

+1

jcogilvie · 9 months ago

In the latest version it's gotten even worse for me; now, my mouse wheel scroll is actually scrolling between messages I have already sent.

Workaround for scrolling for me (zsh, macos) is shift+pgup/pgdn.

LuyiTian · 7 months ago

I am using 2.0.45 and still have this problem

ironicviking · 7 months ago

Same, im on 2.0.47 (linux) and am also seeing the issue.

jbarraquand · 7 months ago

Same problem here, just moved to 2.0.55, scrolling does not work, terminal unusable

jbarraquand · 7 months ago
Same problem here, just moved to 2.0.55, scrolling does not work, terminal unusable

found the issue. the scrolling problem came from the terminal. close ti and reopened a new terminal window. claude cli works fine in the most recent version 2.0.55

nzifnab · 7 months ago

Seeing this now on 2.0.69, this wasn't an issue last Friday but now I am unable to scroll up after claude finishes it's response. Closing the terminal and opening again didn't fix anything.

I'm on Windows WSL using the windows command prompt / default ubuntu profile

github-actions[bot] · 6 months ago

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.

jdz-zhang · 5 months ago

Confirming scroll regression on Ghostty + macOS

Environment:

  • Terminal: Ghostty (latest)
  • OS: macOS Darwin 25.2.0
  • Claude Code: Apple-wrapped v0.0.124 (Anthropic v2.1.5)

Symptoms:

  • Mouse wheel scrolling in main conversation view scrolls input history, not conversation output
  • Transcript view (Ctrl+O) also has no working scroll - none of the expected keys work (Page Up/Down, arrow keys, j/k, Ctrl+U/D, Ctrl+B/F)
  • Mouse scrolling works fine in regular Ghostty windows, only broken in Claude Code sessions

Notes:

  • Scrolling previously worked on this setup with an older Claude Code version
  • This makes reviewing long responses or debugging sessions very difficult
kshtompel · 5 months ago

+1

jaroslawjanas · 5 months ago

I just encountered this.
It scrolls prompt history instead of the terminal window.

I am on W10 Powershell 7.5.4
Claude version 2.1.32.

Downgrading to 2.1.31 did not help (it worked before for sure)
Doesn't seem to be a Claude issue, restarting the Terminal (closing an opening a new instance) fixed it.

nicoache1 · 5 months ago

Additional reproduction case: iTerm2 Split Panes

I'm experiencing a related scroll issue specifically when using iTerm2 split panes:

  • Behavior: Scroll works correctly in a normal iTerm2 window, but breaks when Claude Code is running inside an iTerm2 split pane
  • Version: 2.1.36
  • OS: macOS (Darwin 25.2.0)
  • Terminal: iTerm2 with split pane configuration

This suggests the scroll issue may be related to how Claude Code handles terminal dimensions or viewport detection when the terminal is split.

scapeshift-ojones · 4 months ago

This scroll regression is one piece of a broader problem: Claude Code has no working mechanism to review conversation history once the active context moves forward. Whether it's scroll loss (this issue), post-compaction inaccessibility, broken branch navigation, or plan-mode context severance — the root cause is the same: data preserved in JSONL, no TUI to access it.

This is consolidated in #27242 alongside 12 other related issues totaling 118+ combined thumbs-up. If you've been affected by the inability to scroll back through history, please 👍 and comment on #27242 — we need consolidated engagement to get past the triage threshold.

skeid21 · 4 months ago

I'm experiencing this issue as of version 2.1.63.

healqq · 2 months ago

Happens in 2.1.119 on macOS

clutchthrower · 2 months ago

WORKAROUND: enter "copy mode" by pressing Ctrl+b, then [. Use the arrow keys to navigate, press q to exit.

zwhite · 1 month ago

This was fixed at one point, but has been reintroduced at least as of 2.1.145. There is no way to scroll using my trackpad now, I can only scroll within the window using page up/down. Highly annoying, and it makes claude much less useful.

It works correctly in 2.1.119. It works incorrectly in 2.1.145.

bog-dance · 1 month ago

Adding evidence that this regression on 2.1.145+ is driven by a server-side GrowthBook A/B experiment, not just a code change in the version itself. Same Claude Code binary (2.1.150) on the same machine, same terminal (Ghostty 1.3.1 on macOS):

  • Account A (userID de5f64…1902c): scroll broken
  • Account B (userID c1dccc…7137e11): scroll works

Diffing ~/.claude.json cachedGrowthBookFeatures between the two accounts, the most suspicious differing flag is:

  • tengu_cedar_inlet: "step" on the broken account, "off" on the working one

Reproduced cleanly with a third profile (copy of the broken account's config dir):

  1. Copy broken profile → scroll broken
  2. Overwrite cachedGrowthBookFeatures from the working account into the copy's .claude.json (cedar_inlet flips to "off" plus a few related boolean flags) → scroll works
  3. Flip just tengu_cedar_inlet back to "step" → scroll breaks again

Symptom matches alt-screen buffer behavior: when broken, the new Claude session draws from the top of the terminal (\e[?1049h-style takeover); when working, it draws inline at the bottom and the scrollback stays intact.

Patching the local file alone is not a stable fix — the client refetches GrowthBook flags from the server on every start and overwrites the value back to "step" for the assigned userID. The only reliable workaround I have right now is replacing the entire cachedGrowthBookFeatures block before each launch, but that breaks again as soon as the server reasserts the assignment.

Could the team either (a) gate tengu_cedar_inlet=step behind something the user can opt out of, or (b) ensure that branch falls back to inline rendering instead of the alt-screen path when the host terminal supports native scrollback? Happy to provide the full flag diff between the two accounts privately if it helps narrow it down.

bog-dance · 1 month ago

Correction / fuller picture on my previous comment — I framed it as just tengu_cedar_inlet but the actual fix that's holding right now is replacing the entire cachedGrowthBookFeatures block on the broken account with the working account's, which flips a much wider set of flags. Posting the full diff in case the relevant variable is one of the others, or a combination.

In the bisect, tengu_cedar_inlet="step" was sufficient to break scroll on its own (set it on top of an otherwise-working flag set → scroll broke). I didn't verify it was necessary — i.e. whether leaving cedar_inlet=step but flipping everything else to the working values would have fixed it. So treat the single-flag callout as a strong suspect, not a confirmed root cause.

Full diff between the two accounts (same machine, same Claude Code 2.1.150, same terminal):

Boolean flags — True on broken account, False on working:

  • tengu_amber_prism
  • tengu_flint_harbor
  • tengu_mcp_subagent_prompt
  • tengu_orchid_mantis_v2
  • tengu_pewter_brook

Boolean flags — False on broken, True on working:

  • tengu_amber_lark
  • tengu_birch_compass
  • tengu_ccr_bridge_multi_session
  • tengu_cobalt_heron
  • tengu_coral_beacon
  • tengu_dune_wren
  • tengu_ember_latch
  • tengu_garnet_finch
  • tengu_gleaming_fair
  • tengu_gypsum_kite
  • tengu_shale_finch
  • tengu_slate_finch
  • tengu_slate_moth

Non-boolean diffs:

  • tengu_cedar_inlet: "step" (broken) vs "off" (working)
  • tengu_pewter_lark: "off" (broken) vs "copy_a" (working)
  • tengu_malort_pedway.enabled: false (broken) vs true (working); autoTargetDisplay: true vs false
  • survey-probability configs differ (tengu_bad/good_survey_transcript_ask_config, tengu_feedback_survey_config) — these almost certainly aren't related to rendering

The flags reading like they're about rendering/TUI behavior (and therefore plausible suspects beyond cedar_inlet) are tengu_orchid_mantis_v2, tengu_ccr_bridge_multi_session, tengu_pewter_lark ("copy_a" sounds copy-mode adjacent), and tengu_malort_pedway. The rest read as feature-flag codenames I can't decode from outside.

Happy to run more targeted bisects if useful — just need a couple of hours per flag because each test cycle requires restarting Claude in a fresh terminal tab.

akaDJon · 1 month ago

run in claude /tui
if you see "fullscreen" try type /tui default
/exit

and start new claude

its helped for me return to normal scroll behavior

zombiehub · 15 days ago

Why is mouse scrolling so fucking retarded???? It's lagging very bad, and super easy to lose the track of where you are ???? FUCK THIS SHIT