Avoid clearing the terminal scrollback

This would be helpful for a variety of use cases:

1. Want to clear the context without losing my chat history
2. Was doing work in the terminal before opening claude
3. Moving the terminal (obviously haha)

This would be great to make the context of claude separate from the context of my window.

!Image
Ctrl+L doesn't properly clear the terminal, and /clear clears the context.

~CMD+K and then press ESC cleared the console in pycharm for me on MAC (prevents the annoying scroll issues when the terminal histroy gets too long) without clearing the current context.~

nevermind, the history just reappears after it begins to scroll again.

The is surely the number 1 most important Issue. I've also found that scrollback all gets deleted when I use Ctrl-G to edit the prompt in Vim, and then exit vim.

please fix this!!! this is f**king annoying...!!!

Its really really bad DX, this should be fixed, losing important context is not acceptable

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.

Still occurring.

Environment: macOS + iTerm2

My use case: When I run /compact or /clear, I understand that the conversation context needs to be cleared or compressed. However, I want to preserve the terminal
scrollback so I can scroll up and review the previous conversation with Claude Code.

Currently, these commands clear both the context AND the terminal scrollback buffer, which makes it impossible to reference earlier parts of the session.

Expected behavior: /compact and /clear should only affect Claude Code's internal conversation state, not the terminal's scrollback history.

Adding my voice to this request. The scrollback clearing on compaction is particularly painful — I lose the audit trail of what I started working on, previous command outputs, and session context.

The terminal is shared workspace between Claude and the human. Clearing scrollback removes valuable history that helps me maintain orientation in long sessions.

Would strongly support either:

1. A config option to disable scrollback clearing
2. Operating in alternate screen buffer (as suggested in the original issue)

https://github.com/anthropics/claude-code/issues/2479#issuecomment-3409450697:

I've also found that scrollback all gets deleted when I use Ctrl-G to edit the prompt in Vim, and then exit vim.

Ditto Helix.

The combination can be quite painful. The plan I am working on only reflects part of a larger change I discussed with Claude Code. Then my scrollback buffer gets nuked, and I can't go back to revisit (of copy / save) the earlier discussion.

Please fix!

Yeah this one really sucks.

I have a workaround that's kind of working okay. I open a /remote-control before a compact or a clear and I can see it in my claude mobile app. Not as great of course, but it kind of works when it's not frozen.

Workaround — preserve scrollback by running Claude Code in a tmux session:

tmux new-session -s claude -d 'HISTSIZE=50000 claude'
tmux attach -t claude

tmux maintains its own scrollback buffer independently of the terminal, so even if Claude Code clears the terminal screen, you can scroll up in tmux (Ctrl+B then [ to enter scroll mode, then Page Up/Down).
Alternatively — configure tmux to preserve more history:

set-option -g history-limit 50000

Workaround 2 — Terminal-specific scrollback protection:
Some terminals let you prevent applications from clearing scrollback:

• iTerm2: Preferences → Profiles → Terminal → uncheck "Allow apps to change scrollback buffer"
• Kitty (kitty.conf):

``
scrollback_lines 10000
clear_all_mouse_actions no
``

• Alacritty: Alacritty doesn't support preventing apps from clearing scrollback, so tmux is the best option.

Workaround 3 — Log output to file:

claude 2>&1 | tee ~/claude-session-$(date +%Y%m%d-%H%M%S).log

This captures all output to a file you can review later, regardless of terminal scrollback state.

Root cause and CLAUDE_CODE_NO_FLICKER=1 test results from tmux

I traced the scrollback clearing to \e[3J (CSI 3 J — "Erase Scrollback") in the bundled ansi-escapes clearTerminal function. Ink enters fullscreen mode when output height >= terminal rows and emits clearTerminal on every render cycle. The sequence is \e[2J (erase screen) + \e[3J (erase scrollback) + \e[H (cursor home). The \e[3J is the destructive one.

Note on the tmux workaround suggested above: Running Claude Code inside tmux does NOT protect scrollback. tmux processes CSI 3 J and clears pane history — same [0/0] result. The terminal-overrides ',*:E3@' trick also fails because Ink constructs escape sequences as string literals at module load time, never querying terminfo.

CLAUDE_CODE_NO_FLICKER=1 on 2.1.89 (tmux 3.4, Debian 13):

This moves rendering to the alternate screen buffer — exactly what the original issue description suggested. Scrollback survives. However, it introduces scroll sensitivity issues (~5 wheel clicks per line), color changes, and sluggish responsiveness — likely caused by the separate eraseLines() cursor-up overflow bug (see #9935, PR #35683).

The clean fix would be removing \e[3J from clearTerminal when running in a terminal multiplexer (the ansi-escapes library already checks $TMUX for OSC wrapping). That eliminates scrollback destruction without the side effects of alt-screen rendering.

Detailed root cause analysis with a working sed patch for cli.js posted in #16310.

— Väinämöinen / Pulsed Media

This issue is 9+ months old and still open. Context compaction clears the entire terminal scrollback buffer, which is extremely disruptive during long working sessions — especially in tmux where scrollback is the primary way to review prior output. Is there an expected ETA on a fix? This is a highly inconvenient issue that impacts daily usability.

Adding a data point: the scrollback regression was bisected by multiple users to v2.1.76 (March 14). Before that version, scrollback worked. After, it's capped to ~300-350 lines even at 54% context.

The root cause appears to be a hardcoded render buffer cap introduced to fix #21806 (55K rows → 100% CPU, 5.7GB RAM). The fix overcorrected — the cap is too aggressive and not configurable.

Users are asking for a tui.maxScrollbackLines setting in settings.json (or similar) — a conservative default (5,000 lines) that prevents the #21806 scenario while letting power users opt into larger buffers.

Separately, CLAUDE_CODE_NO_FLICKER=0 partially mitigates by keeping CC on the primary screen buffer (where terminal scrollback works), but the \e[3J in Ink's clearTerminal still destroys scrollback on re-renders.

Environment: CC v2.1.90, macOS, Ghostty + Terminal.app.

Why is no one at Anthropic looking at this issue? Is it because the less people can review Claude's actual outputs, the less they will likely find issues with it and it perpetuates the cycle? Is that the real reason? So just secretly keep wiping terminal history?

Workaround: I wrote crabtail.sh — a bash+jq script that tails your session's JSONL transcript in a separate terminal tab. Full scrollback from line 1, live-updating, with color-coded tool results (✓/✗) and basic markdown rendering. No dependencies beyond bash and jq.

crabtail.sh                  # most recent session (auto-detects project dir)
crabtail.sh my-session       # by /rename (partial match)

Name your session with /rename so you can target it. If you're on Ghostty, bumping scrollback-limit = 25000000 in your config gives the tail tab ~250K lines of buffer.

Built and tested on Ghostty — not a fix, but a readable mirror of your conversation while the alt-screen issue gets resolved.

I dug into the call chain and the source is Ink's render loop, not Claude Code or any terminal emulator. Details in #16310 and a full write-up here:

Full analysis: root cause chain, cross-terminal table, working fixes

For those using the JSONL tail workaround from this thread, it remains the most resilient approach. Append-only on disk, unaffected by anything Ink or the terminal does. The cli.js sed patch (documented in the Gist) fixes the scrollback wipe at the emission point, but the JSONL tail is belt-and-suspenders that works regardless of future rendering changes.

The fix needs to land in vadimdemedes/ink. Ink should use eraseScreen + cursor-home in its render path instead of the full clearTerminal sequence. Three fix options are in the Gist.

@MagnaCapax nice rca. The \e[3J in Ink's render loop is confirmed destructive across every VT-compliant terminal.

One additional finding for Ghostty users: removing \e[3J alone is not sufficient for Ghostty. After patching out \e[3J, the remaining \e[2J (Erase Display) in the clearTerminal sequence still destroys visible content in Ghostty because Ghostty follows the strict VT spec — CSI 2 J erases the display without pushing content to scrollback (Ghostty ED docs). iTerm2, Terminal.app, and tmux non-standardly push content to scrollback on \e[2J, which is why the \e[3J-only fix works for those terminals but not Ghostty.

Ghostty-specific workaround: Replace eraseScreen (\e[2J) with \e[99S (CSI Scroll Up 99 lines) in the clearTerminal template. Since Ghostty 1.3.0 (PR ghostty-org/ghostty#9907), CSI n S correctly preserves scrolled-off lines in scrollback. The result is the same visual effect (blank screen for Ink to redraw) but content is pushed to scrollback first.

So the full picture is a two-layer bug:

• Layer 1: \e[3J — cross-terminal, destructive in every VT-compliant terminal (your finding)
• Layer 2: \e[2J — Ghostty-specific, because Ghostty's strict VT doesn't push to scrollback on ED

Your proposed upstream fix (Option A: \e[2J\e[H in Ink's render path) solves Layer 1 for all terminals but leaves Layer 2 open for Ghostty. An Ink fix that uses \e[99S\e[H instead would solve both layers — though CSI S respects scroll regions (DECSTBM) unlike CSI 2 J, so it may need a \e[2J fallback for terminals where scroll regions are active.

Post-2.1.101 follow-up on our April 10 observation.

Byte-level measurements on 2.1.114 confirm zero CSI 3J — the chain we named is closed as intended. Scrollback loss continues via the remaining CSI 2J + CSI H render-loop cadence on emulators that treat CSI 2J as scrollback-destructive (ConPTY, xterm.js).

Detail and mitigation attempts: #42670.

Update: posted a working two-part workaround for the post-2.1.101 CSI 2J render-loop scrollback issue on WSL2/Win11. Combines CLAUDE_CODE_NO_FLICKER=1 (alt-screen, preserves scrollback) with stdin-side amplification of SGR wheel events (restores usable wheel sensitivity that NO_FLICKER alone destroys).

Full detail: #42670.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.