Allow scrolling back to view full conversation history in CLI TUI

Open 💬 36 comments Opened Feb 24, 2026 by SunkyYang

Problem

In the Claude Code CLI (TUI mode), older messages in a conversation become invisible and cannot be scrolled back to, even before context compression kicks in. The terminal's own scrollback buffer (e.g., Ghostty scrollback-limit = 100000) has no effect because Claude Code uses the alternate screen buffer, which bypasses terminal scrollback entirely.

This means critical information is lost from view during a session:

  • Tool call results (file contents, command output, search results)
  • Code diffs and changes made earlier in the conversation
  • Architectural decisions and reasoning from earlier messages
  • Error messages and debugging context

There is no user-configurable setting (settings.json, environment variable, or CLI flag) to control how many messages are rendered in the TUI.

Proposed Solution

  1. Virtual scrolling in TUI - Render only visible messages in the viewport, but allow scrolling back through the full conversation history (similar to how terminal multiplexers handle scrollback)
  2. Configurable render limit - At minimum, expose a setting (e.g., maxRenderedMessages or tui.scrollbackLines) so users can control how much history is kept renderable
  3. Lazy rendering on scroll - Load and render older messages on demand when the user scrolls up, rather than discarding them

Environment

  • Claude Code v2.1.51
  • Terminal: Ghostty (also reproducible in iTerm2, Terminal.app)
  • OS: macOS

Related

  • #24146 - Virtual scrolling for Web UI (same problem, different platform)

View original on GitHub ↗

36 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/13446
  2. https://github.com/anthropics/claude-code/issues/18204
  3. https://github.com/anthropics/claude-code/issues/9001

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

SunkyYang · 4 months ago

This is not a duplicate of the three referenced issues. Those are all related to compaction/compression clearing the screen:

  • #13446 - After compaction the terminal resets
  • #18204 - Compaction clears screen
  • #9001 - Scroll regression (also tied to context window resets)

My issue is fundamentally different: older messages become unviewable even before any compaction occurs. In a single session with no compression triggered, earlier messages (tool results, code diffs, reasoning) simply disappear from the TUI viewport and cannot be scrolled back to.

The root cause is that Claude Code's TUI uses the terminal's alternate screen buffer, which bypasses the terminal's own scrollback entirely. The terminal's scrollback-limit setting (e.g., Ghostty's 100,000 lines) has zero effect. And there is no internal setting to control how many messages the TUI keeps renderable.

This needs to be addressed separately from the compaction-related scroll issues.

arkevo · 4 months ago

I'm having the same issue

casepot · 4 months ago

Also having this. Losing the majority of conversation history visible to me. How does a regression like this get through? It makes it impossible to understand what was going on if you step away for a second. Ctrl+o and ctrl+e seem to lose the history too?

cstelmach · 4 months ago

Opus summary:

Working version: v2.1.72 (March 10)
Broken version: v2.1.76 (March 14) - TUI scroll history noticeably shorter

Setup:

  • Terminal: Ghostty (scrollback-limit = 52428800 / 50MB)
  • Also tested inside tmux (history-limit 100000)
  • Neither helps — the limit is inside Claude Code's TUI, not the terminal

What I see: During a normal session (no compaction, no /clear, no resize), scrolling up hits a hard wall well before the full conversation history. Earlier tool outputs, code diffs, and reasoning are simply gone from the viewport. This started after updating from v2.1.72.

Likely cause (according to Opus 4.6): The fix for #21806 (55K-row scrollback causing 100% CPU / 5.7GB RAM) probably introduced a hard cap on the TUI's internal render buffer. Understandable — but the current cap is too aggressive for power users running multi-hour agentic sessions.

Proposal: Expose a configurable setting (e.g., tui.maxScrollbackLines) with a conservative default (e.g., 5,000 lines) that prevents the #21806 scenario while letting users opt into larger buffers at their own risk:

// ~/.claude/settings.json

{
	"tui": {
	  "maxScrollbackLines": 20000
	}
}

This is a one-line constant change on the Anthropic side — the renderer already has the cap, it just needs to read it from config instead of hardcoding it.

bllshttng · 4 months ago

Please work on this. As a workaround, I've been enabling /remote-control so I can see my history on the claude mobile app.

This also works for /clear and /compact for now.

aluxian · 3 months ago

+1, annoyingly broken

zzelner · 3 months ago

+1 @bcherny plz help

davecazz · 3 months ago

An example of a real world case where this is critical

  • give claude code a prompt with a bunch of bugs
  • claude code fixes bugs
  • claude code changes how it describes bugs form the original prompt
  • cant scrollback up and see the original prompt with my description of the bugs so I can properly test
DrAlexHarrison · 3 months ago

Recommendation: Consider labeling this a bug.

It is killing my ability to be effective in long-context conversations, especially across multiple sessions. It is a barrier to rapid development with decent quality control.

[!IMPORTANT] Need exposed scrollback setting badly for power users.

Kernel: 6.8.0-106-generic
Distro: Linux Mint 22.3 Zena
Claude Code: v2.1.80

georgesamuelson · 3 months ago

Power user running multi-hour operational sessions (1,500+ sessions, institutional memory across projects). This regression from v2.1.72→v2.1.76 has completely broken a core workflow.

My setup: Ghostty 1.3.2 (tip), scrollback-limit = 10000000, macOS, Claude Code 2.1.80. I'm seeing ~300-350 lines of scrollback at 54% context — sessions that used to give me 2,000+ lines of visible history.

In my use case, I'm running long operational sessions that involve transcript digestion, document generation, multi-step task tracking, and cross-referencing earlier outputs. Losing the ability to scroll back to see what happened 20 minutes ago in the same session is a serious regression. I rely on being able to visually verify earlier tool outputs, review generated documents, and cross-reference decisions made earlier in the conversation.

+1 on exposing tui.maxScrollbackLines as a configurable setting. Happy to accept the memory tradeoff — that should be the user's choice, not a hardcoded cap.

guppy-jpf · 3 months ago

just another +1. this has also been sporadically happening to me for the past few months, but it seems to have gotten worse somewhere around 2.1.80 or 2.1.81. mostly what i used to see was that starting a new session in the same terminal tab where a previous session had been running would sometimes destroy all the scrollback from the previous sessions (again, sporadic). now what i'm seeing is that, within the same session, over the course of several hours or days, i will every once in a while want to go back and look at some previous event and find it missing. going all the way to the top of the buffer, more stuff has been truncated every time i check. i haven't seen that behavior before, and it suggests there's some arbitrary cutoff somewhere.
EXTREMELY NOT USEFUL. pretty annoying in fact. macos terminal (sequoia).

FraserLee · 3 months ago

+1, this not being configurable is a major usability regression.

wgordon17 · 3 months ago

This is a _stupid_ workaround...but I can use claude -r to list resumable sessions, then ctrl+v to _preview_ the session that is currently running...for some reason, the _preview_ has a much larger scrollback than a running session. It's still not the full session, but it's at least larger

Morriz · 3 months ago

Plz @claude fix this!

LeeSangMin1029 · 3 months ago

echo 'export CLAUDE_CODE_NO_FLICKER=1' >> ~/.bashrc
이게 도움이 될까요?

davecazz · 3 months ago

it just got worse, in on task 6 of 12, 3000 lines of code written, and have 25 lines total displayed with 0 scrollback

blue-int · 3 months ago

Still happening on v2.1.89 (cmux / Ghostty-based terminal, macOS)

Conversation history becomes invisible after just a few exchanges — context usage is only ~4% (1M context window, Opus 4.6), so this is clearly not compaction-related.

Resizing the terminal partially restores some messages, but earlier turns remain gone from the TUI display. This confirms the data is in context but the renderer is dropping it.

Related: #38884, #40521

Environment:

  • Claude Code v2.1.89
  • cmux 0.63.1 (Ghostty engine)
  • macOS Darwin 25.3.0
  • Model: Opus 4.6 (1M context)
zenrith-fluxman · 3 months ago

v2.1.89 broke my workflow. I backed up ~/.claude/ and ~/.claude.json, removed the native installer, and switched to npm for version control:

npm install -g @anthropic-ai/claude-code@2.1.87

Note: v2.1.88 is not published on npm, so 2.1.87 is the latest version before 2.1.89.

Everything carried over without restoring from backup. Temporary solution until this is fixed.

tvhahn · 3 months ago

I just encountered this bug too when I upgraded to the latest version, 2.1.89, today. Blah. Please work on this. I guess I'll move back to the previous version...

Environment:

  • Claude Code v2.1.89
  • Default Ubuntu/GNOME Terminal
  • Linux 6.8.0-106 (Ubuntu, inside devcontainer)
  • Also reproducible inside tmux (TERM=xterm)
  • Model: Opus 4.6 (1M context)
Timw88 · 3 months ago

This issue turned into a bug report. I am here coming from one of the bug reports mentioned.

For me, this started in v2.1.89 as my older v2.1.87 tabs on the same machine do not have the issue.

This doesn't seem to be triggered by a simple line count threshold. In my testing, the display wipe appears to be triggered specifically by agent and/or skill invocations. Regular back-and-forth conversation can go on for a while, but as soon as agents or skills are spawned, earlier messages start disappearing from the terminal display.

ks582 · 3 months ago

The same issue here:

  • Claude Code v2.1.90
  • terminal: zsh
  • OS: macOS Darwin 25.4.0

In the terminal I can only see the most recent conversation, but cannot trace back to the previous ones.

kurplunkin · 3 months ago

Also just noticed this happening to me today, v2.1.90. Very limited scroll back. Has nothing to do with what I have in my terminal settings which has been unchanged and is a long scroll back of 50,000.

georgesamuelson · 3 months ago

Follow-up to my March 20 comment — it's gotten worse.

Background

Power user running multi-hour operational sessions (1,500+ sessions, institutional memory across projects). Setup: Ghostty 1.3.2, scrollback-limit = 10000000, macOS, Claude Code 2.1.91, tmux.

My sessions involve transcript digestion, document generation, multi-step task tracking, and cross-referencing earlier outputs. I capture full conversation logs via tmux capture-pane + save-buffer — these feed into session resume protocols, compaction recovery, and searchable archives. I rely on being able to visually verify earlier tool outputs, review generated documents, and cross-reference decisions made earlier in the conversation.

Two Compounding Regressions

Regression 1: Internal Render Buffer Cap (v2.1.76)

The Ink TUI renderer now virtualizes scrollback — only ~300 lines are kept in the render tree. Earlier conversation output is dropped from the buffer entirely. This was introduced to fix a memory/CPU issue (#21806), but the cap is far too aggressive for anyone running sessions longer than 10-15 minutes.

Impact: Can't scroll back beyond ~300 lines regardless of terminal settings. Ghostty scrollback-limit = 10000000 has no effect.

User-configurable fix: None. The limit is compiled into the Mach-O binary. No env var, no settings.json option, no patchable constant.

Regression 2: Alternate Screen Buffer (v2.1.89)

Claude Code now uses the terminal's alternate screen buffer (same as vim, htop). This completely bypasses native terminal scrollback.

Impact: tmux capture-pane only grabs what's currently visible — the full conversation never enters tmux's scrollback buffer. The entire logging pipeline silently breaks with no warning.

Partial fix: CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 restores native terminal scrollback, but you're still capped at ~300 lines from Regression 1.

The Combined Effect

With both regressions stacked:

  • Before v2.1.76: Full conversation in terminal scrollback. tmux capture works. 2,000+ lines visible.
  • After v2.1.76: Capped at ~300 lines, but tmux capture still works for what's in the buffer.
  • After v2.1.89: Capped at ~300 lines AND tmux capture gets nothing (alternate screen).
  • With env var workaround: Back to "capped at ~300 lines, tmux capture works" — but still a major regression from pre-v2.1.76 behavior.

Who This Affects

Anyone who:

  • Captures terminal output for logging (tmux, script, tee)
  • Uses terminal search (Cmd+F) to find earlier conversation output
  • Relies on tmux copy mode to review/select previous output
  • Runs sessions longer than ~15 minutes and needs to reference earlier work
  • Pipes terminal output to log files or monitoring tools

The Ask

  1. Expose tui.maxScrollbackLines in settings.json (or CLAUDE_CODE_MAX_SCROLLBACK_LINES env var). Let users choose their own memory tradeoff. A default of 5,000-10,000 lines would cover most use cases without hitting the #21806 memory issue.
  1. Document CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN — it works but is completely undocumented. Users shouldn't have to dig through GitHub issues to find it.
  1. Auto-detect tmux/screen — if $TMUX or $STY is set, default to native scrollback. These users depend on it by definition.
  1. Don't silently break existing workflows. A rendering mode change that kills terminal scrollback should be opt-in, not opt-out — especially when the opt-out isn't documented.
cadamsdotcom · 3 months ago

Also getting hit by this. Can a member of the CC team please weigh in, it really sucked to lose ALL my history.

Now I have to guess what the agent did while I was away.

arkevo · 3 months ago

Any update on this?

radekstepancz · 3 months ago

Seems like this issue has been resolved in 2.1.101 - https://code.claude.com/docs/en/changelog, maybe the:

Fixed rendering issues: flicker in non-fullscreen mode when content above the visible area changed, terminal scrollback being wiped during long sessions in non-fullscreen mode, and mouse-scroll escape sequences occasionally leaking into the prompt as text

I was experiencing this issue and it was driving me crazy, now since Friday I can scroll through full chat history in terminal without any troubles.

markholland · 2 months ago

Still an issue for me on 2.1.118 with ghostty and iterm.

guppy-jpf · 2 months ago

still broken (in a different way now) for me (macos terminal (sequoia); CC .119). scrollback availability is mostly ok, but occasionally something will happen where i leave a window inactive for a while, and when i come back to it, the scrollback is a garbled mess, with the text of the last turn or so repeated multiple times, with intermixed prompt area box-drawing lines, etc. tried resizing the window and then putting it back to the correct default size but it doesn't repair the damage. unusable is just as bad as missing.

twf-nikhila · 2 months ago

using v2.1.138 still having this problem

Any fix for this yet?

guppy-jpf · 2 months ago

in the interest of keeping this thread alive, i'm also still seeing the same behavior, as of 2.1.140.

serhii-chernenko · 17 days ago

any updates?

riccardo-manenti · 14 days ago

Fix: Check your ~/.claude/settings.json — if "tui": "fullscreen" is set, change it to "tui": "default" and restart Claude Code. Scrollback
works again.

danelec-hpm · 3 days ago
Fix: Check your ~/.claude/settings.json — if "tui": "fullscreen" is set, change it to "tui": "default" and restart Claude Code. Scrollback works again.

This is not an issue about scroll back not working, it's an issue that you only have a limited amount of lines you can scroll back and see in the terminal, and since Claude uses it's own implementation of scrolling, and not the terminals native scrolling, it's impossible to set how many conversion lines or how far back the history goes. What the author or original poster wants is to be able to configure how far back the history goes or how many terminal lines that Claude CLI should be able to display, also known as depth. This is in other words a request to implement a new setting in Claude to control this.
I myself had the same issue and found this thread. I asked for some step by step instructions and after having some questions to the instructions, the instructions are now gone/out of view. I could of course have asked Claude to write a file with the instructions, and I can of course ask Claude to repeat the instructions, but if I could just scroll furtherup the conversation and find it, it would have been more easy for me and also use less tokens.

danelec-hpm · 3 days ago
## Problem In the Claude Code CLI (TUI mode), older messages in a conversation become invisible and cannot be scrolled back to, even before context compression kicks in. The terminal's own scrollback buffer (e.g., Ghostty scrollback-limit = 100000) has no effect because Claude Code uses the alternate screen buffer, which bypasses terminal scrollback entirely. This means critical information is lost from view during a session: Tool call results (file contents, command output, search results) Code diffs and changes made earlier in the conversation Architectural decisions and reasoning from earlier messages Error messages and debugging context There is no user-configurable setting (settings.json, environment variable, or CLI flag) to control how many messages are rendered in the TUI. ## Proposed Solution 1. Virtual scrolling in TUI - Render only visible messages in the viewport, but allow scrolling back through the full conversation history (similar to how terminal multiplexers handle scrollback) 2. Configurable render limit - At minimum, expose a setting (e.g., maxRenderedMessages or tui.scrollbackLines) so users can control how much history is kept renderable 3. Lazy rendering on scroll - Load and render older messages on demand when the user scrolls up, rather than discarding them ## Environment Claude Code v2.1.51 Terminal: Ghostty (also reproducible in iTerm2, Terminal.app) OS: macOS ## Related Virtual scrolling / lazy-load for long conversations in Web UI #24146 - Virtual scrolling for Web UI (same problem, different platform)

Try to press CTRL+O that should show the full conversation.

Yan-Yu-Lin · 3 days ago

Hi all — I think I might have the thing this thread has been asking for.

This one — not being able to get back to your full conversation history in the terminal — is exactly what drove me nuts. On recent versions Ctrl+O only expands the most recent chunk, collapsing doesn't fold the older stuff back, and resizing mangles what's already on screen. And the usual answer (fullscreen / NO_FLICKER=1) I refuse to use, because it hijacks the terminal and kills native scrollback.

So I fixed it myself. The app's code is bundled inside the native binary, and it turns out you can patch it in place (same-length edits + re-sign) to make the classic non-fullscreen renderer behave properly again. An AI agent helped with the low-level part.

After patching, in normal mode:

  • Ctrl+O expands the full transcript — all of it, including tool calls
  • Ctrl+O again collapses everything and re-renders cleanly
  • resizing does a clean repaint instead of duplicating/garbling

Upfront about scope: macOS / Apple Silicon (arm64), tied to a specific version (done 2.1.203 and 2.1.207). It patches a copy and installs as a separate command — your normal claude stays exactly as-is. It's a community hack, not an official fix. Linux/Windows aren't built yet, but the same JS lives inside every platform's binary, so the repo explains how you or your own AI agent can reproduce it on your OS.

Repo: https://github.com/Yan-Yu-Lin/claude-code-renderpatch

If it helps you, a ⭐ lets me know it's useful beyond just me — and if it doesn't work or you get stuck, open an issue on the repo and I'll help.

---
Note: drafted with Claude — English isn't my first language, so the AI helped me word this. The fix and the repo are my own.