[BUG] Bug: Tmux scrollback buffer cleared during autocompact/compact

I wonder if there is any progress or workarounds? It is indeed inconvenient look the scroll back buffer.

I am frustrated and impeded by this behavior on a daily basis. Useful conversations/content are frequently deleted after compacting a conversation. I do not understand why claude needs to modify my scrollback in order to compact or clear context.

+1 — This is a serious UX problem. Context compaction is an internal optimization and should be invisible to the terminal experience. Losing scrollback mid-session means losing reference to earlier test output, command results, and conversation history that the user is actively working with. Competing tools (e.g., Codex) preserve scrollback regardless of internal context management. Terminal display and context window are separate concerns.

Note the conversation history is still stashed somewhere under ~/.claude, so it is not lost irreversibly. If you insist a bit, Claude will be able to pull it.

This said, I agree the current behaviour is rather annoying and seems to be absolutely pointless.

Note the conversation history is still stashed somewhere under ~/.claude, so it is not lost irreversibly. If you insist a bit, Claude will be able to pull it. This said, I agree the current behaviour is rather annoying and seems to be absolutely pointless.

Just to clarify: It's not just the loss of claude conversation history -- it's the whole frickin' terminal history that gets wiped, eg anything and everything that was in the term history before claude was even run. Very, very aggravating UX behavior. Unwanted, surprising, and unwarranted.

Still happening on v2.1.78 (Linux, tmux 3.5a). This started after upgrading from 2.1.77 →
2.1.78 on March 17, 2026 — was not experiencing this on 2.1.77.

Evidence: Mid-session, tmux display-message -p '#{history_size}/#{history_limit}' shows
155/100000 — the scrollback is being actively wiped, not overflowed. I was able to scroll
back to the beginning of the conversation earlier in the same session, then after a
re-render/compaction event the scrollback was truncated.

Environment:

• Claude Code 2.1.78
• tmux 3.5a (Homebrew/Linuxbrew)
• Linux 6.17.0-14-generic
• history-limit 100000
• alternate-screen on (default)

Root Cause Found — \e[3J in ansi-escapes clearTerminal

I tracked this down to the exact source. The ansi-escapes library bundled in cli.js defines:

clearTerminal = process.platform === "win32"
    ? `${eraseScreen}${ESC}0f`
    : `${eraseScreen}${ESC}3J${ESC}H`;

The \e[3J (CSI 3 J = "Erase Scrollback") is the destructive sequence. It tells the terminal emulator to wipe the scrollback buffer. tmux processes this and clears the pane's history, resulting in [0/0].

Ink enters "fullscreen mode" when outputHeight >= stdout.rows (around line 320 of ink.js in the bundle) and emits clearTerminal on every render cycle — so scrollback is destroyed repeatedly, not just during compaction.

Confirming 2.1.78 regression

@Khandurian's observation matches — 2.1.72 works, 2.1.78+ is broken. Something changed in the Ink rendering path between those versions that triggers fullscreen mode more aggressively.

Working patch

Remove \e[3J from the two clearTerminal definitions in the bundle. In 2.1.80, the minified variable names are JY/iz and MY/rz:

sed -i 's/\${JY\.eraseScreen}\${iz}3J\${iz}H/${JY.eraseScreen}${iz}H/g' cli.js
sed -i 's/\${MY\.eraseScreen}\${rz}3J\${rz}H/${MY.eraseScreen}${rz}H/g' cli.js

This preserves screen clearing (\e[2J) and cursor homing (\e[H) — only the scrollback destruction is removed. tmux scrolling works again after patching.

Note on tmux terminal-overrides

set -ga terminal-overrides ',*:E3@' does not fix this because Ink constructs escape sequences as string literals at bundle load time — it never queries terminfo. The raw \e[3J bytes go straight to tmux's input parser regardless of capability overrides.

Proper upstream fix

The clearTerminal function should not use \e[3J at all — or at minimum, should detect tmux ($TMUX env var is already checked in ansi-escapes for OSC wrapping) and omit \e[3J when running inside tmux.

Environment: Claude Code 2.1.80, tmux 3.5a, Linux, TERM=tmux-256color

Update: CLAUDE_CODE_NO_FLICKER=1 on 2.1.89 — fixes one bug, reveals another

Tested the NO_FLICKER env var on 2.1.89 inside tmux (tmux 3.4, Debian 13).

What it fixes: Scrollback destruction is gone. The alt-screen buffer keeps \e[3J away from tmux's main scrollback. Mouse wheel enters copy-mode with actual content — no more [0/0].

What it breaks:

• Scroll sensitivity: ~5 mouse wheel clicks to move 1 line. Native tmux scrolling in other panes works normally — isolated to the Claude Code pane.
• Color rendering: Different color scheme compared to normal main-screen mode.
• General responsiveness: Noticeably sluggish.

Two-bug model confirmed:

1. \e[3J scrollback destruction (this issue) — NO_FLICKER fixes it by rendering in the alternate screen buffer.
2. eraseLines() cursor-up overflow — persists in NO_FLICKER mode. Likely the cause of the broken scroll sensitivity. The cursor-up sequences that overflow the viewport in main-screen mode manifest as extreme scroll insensitivity in alt-screen mode.

The binary patch from my earlier comment (removing \e[3J from clearTerminal in cli.js) fixes only bug 1. Bug 2 requires clamping the cursor-up count in eraseLines() to min(linesToErase, stdout.rows) — which is what PR #35683 addresses.

Net result: NO_FLICKER trades one set of tmux problems for another. Still pinned to 2.1.72 for interactive tmux sessions.

Environment: Claude Code 2.1.89, tmux 3.4, Debian 13 (trixie), CLAUDE_CODE_NO_FLICKER=1

— Väinämöinen / Pulsed Media

I traced this to Ink's render loop.

The call chain: ansi-escapes defines clearTerminal as eraseScreen + \e[3J + cursor-home (VT-spec correct), but vadimdemedes/ink calls it on every render cycle when output exceeds the viewport. A repaint should never touch scrollback. This was partially identified in ink#359 back in 2020, but that issue was closed without fixing the render path, and the Anthropic threads haven't connected back to it.

Every terminal that implements VT correctly honors CSI 3 J: tmux, GNU screen, xterm.js (and everything built on it: ttyd, code-server, VS Code, Cursor), Microsoft Terminal, WezTerm, Alacritty, Kitty, Ghostty. Only iTerm2 on macOS has an opt-out. Full cross-terminal table, Ink fix options, and the cli.js sed patch:

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

For anyone on non-macOS right now: the working paths are (a) the cli.js sed patch (strips \e[3J from the bundled clearTerminal), (b) pinning to around 2.1.75, or (c) raw TTY SSH without any multiplexer.

Happy to file this against Ink if nobody at Anthropic is already on it.

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 is a duplicate of #34718, which was fixed as of version 2.1.101.

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.