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
- 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)
- Configurable render limit - At minimum, expose a setting (e.g.,
maxRenderedMessagesortui.scrollbackLines) so users can control how much history is kept renderable - 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)
36 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is not a duplicate of the three referenced issues. Those are all related to compaction/compression clearing the screen:
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-limitsetting (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.
I'm having the same issue
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?
Opus summary:
Working version: v2.1.72 (March 10)
Broken version: v2.1.76 (March 14) - TUI scroll history noticeably shorter
Setup:
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
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.
Please work on this. As a workaround, I've been enabling
/remote-controlso I can see my history on the claude mobile app.This also works for
/clearand/compactfor now.+1, annoyingly broken
+1 @bcherny plz help
An example of a real world case where this is critical
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.
Kernel: 6.8.0-106-generic
Distro: Linux Mint 22.3 Zena
Claude Code: v2.1.80
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.maxScrollbackLinesas a configurable setting. Happy to accept the memory tradeoff — that should be the user's choice, not a hardcoded cap.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).
+1, this not being configurable is a major usability regression.
This is a _stupid_ workaround...but I can use
claude -rto 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 largerPlz @claude fix this!
echo 'export CLAUDE_CODE_NO_FLICKER=1' >> ~/.bashrc
이게 도움이 될까요?
it just got worse, in on task 6 of 12, 3000 lines of code written, and have 25 lines total displayed with 0 scrollback
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:
v2.1.89 broke my workflow. I backed up
~/.claude/and~/.claude.json, removed the native installer, and switched to npm for version control: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.
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:
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.
The same issue here:
In the terminal I can only see the most recent conversation, but cannot trace back to the previous ones.
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.
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 = 10000000has 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-paneonly 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=1restores native terminal scrollback, but you're still capped at ~300 lines from Regression 1.The Combined Effect
With both regressions stacked:
Who This Affects
Anyone who:
Cmd+F) to find earlier conversation outputThe Ask
tui.maxScrollbackLinesin settings.json (orCLAUDE_CODE_MAX_SCROLLBACK_LINESenv 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.CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN— it works but is completely undocumented. Users shouldn't have to dig through GitHub issues to find it.$TMUXor$STYis set, default to native scrollback. These users depend on it by definition.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.
Any update on this?
Seems like this issue has been resolved in 2.1.101 - https://code.claude.com/docs/en/changelog, maybe the:
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.
Still an issue for me on
2.1.118with ghostty and iterm.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.
using v2.1.138 still having this problem
Any fix for this yet?
in the interest of keeping this thread alive, i'm also still seeing the same behavior, as of 2.1.140.
any updates?
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.
Try to press CTRL+O that should show the full conversation.
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:
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
claudestays 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.