[Critical UX Regression] No way to access conversation history — alternate screen buffer kills all scrollback (v2.1.89+)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/41965
2. https://github.com/anthropics/claude-code/issues/42024
3. https://github.com/anthropics/claude-code/issues/42340

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

Cross-posting from my comment on #28077 — these two issues are compounding.

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.

Two Compounding Regressions

Regression 1: Internal Render Buffer Cap (v2.1.76) — see #28077

~300 line hard cap in the Ink TUI renderer. No user-configurable fix. Compiled into the binary.

Regression 2: Alternate Screen Buffer (v2.1.89) — this issue

Completely bypasses native terminal scrollback. tmux capture-pane gets nothing.

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

The Combined Effect

• Before v2.1.76: Full conversation in scrollback. tmux capture works. 2,000+ lines visible.
• After v2.1.76: Capped at ~300 lines, tmux capture still works.
• After v2.1.89: Capped at ~300 lines AND tmux capture gets nothing.
• With env var: Back to ~300 lines with tmux capture working — still a major regression.

The Ask

1. Expose tui.maxScrollbackLines in settings.json or as env var
2. Document CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN — it works but is undocumented
3. Auto-detect tmux/screen ($TMUX/$STY) and default to native scrollback
4. Don't silently break existing workflows — rendering changes that kill scrollback should be opt-in

Full details in my comment on #28077.

Confirming this regression on v2.1.90 (macOS, Terminal.app). With the 1M context window (Opus 4.6), conversations get long fast — and losing scrollback makes it impossible to review what happened earlier in the session. Ctrl+O transcript mode helps but it's not discoverable and not a substitute for native scrollback. Would appreciate an env var opt-out like CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 or a setting in settings.json.

Still experiencing this on v2.1.90 with macOS Terminal.app.

• CLAUDE_CODE_NO_FLICKER=0 is set and confirmed loaded in the shell
• Scrollback is lost immediately after the first message when sub-agents spawn — not after a long session or context compaction
• Just one user message + CLAUDE.md + MCP configs in context, so this isn't a capacity issue
• Terminal.app on macOS (not iTerm2, Ghostty, etc.)

The env var doesn't appear to prevent the scrollback wipe triggered by the TUI re-render when agent status indicators appear.

I am experiencing the same issue using iTerm2, so I don't think it has to do with Terminal.app specifically. This basically removes my ability to see conversation history, especially since even transcript mode no longer shows anything.

same exact issue on iTerm2, works for a bit and then stops working after I unplug my secondary screen, which is weird

I created https://github.com/drorm/claude-screen mostly to deal with issues with claude in GNU screen, but now it also addresses this issue.
Instead of clearing the screen it outputs

------------------------------------------------------------------

                    Clear screen replacement
  
-------------------------------------------------------------------

If that bothers you, change the code :-).

v2.1.114 — the return, by another path

Origin. The April 9-10 filings (vadimdemedes/ink#935, comments on #16310 and #2479) named the chain: Ink's render-loop clearTerminal expanding to eraseScreen + CSI 3J + CSI H. 2.1.101 struck the CSI 3J. That part holds — byte-level measurements on 2.1.114 confirm zero CSI 3J across multiple session-length samples.

The loss returned through what remained.

Mechanism. Ink still emits CSI 2J + CSI H per render cycle. The VT spec is ambiguous on whether CSI 2J touches scrollback. Emulators disagree. On ConPTY, on xterm.js, on the affected pipelines, CSI 2J behaves as scrollback-destructive. The bytes are individually legal; the damage is cumulative and emulator-specific.

Evidence (aggregate byte-counts across session-length samples on 2.1.114):

| Sequence | Count |
|---|---|
| CSI 3J | 0 |
| Alt-screen toggles (1049/1047/47 h/l) | 0 |
| RIS (\ec) | 0 |
| CSI 2J + CSI H | per-render cadence (dozens per long sample) |
| CUU distribution | varies sample-to-sample — content-dependent Ink redraw strategy |

Mitigations attempted:

• A PTY-proxy stripping CSI 3J, alt-screen variants, and RIS — no-op on 2.1.114 as the counts predict
• CLAUDE_CODE_NO_FLICKER=1 — scrollback survives; wheel-scroll degrades to approximately five events per rendered line, unusable
• CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 — no effect on the tested pipelines
• Cursor-up (CUU) rewriting or clamping toward absolute positioning — caps renderable UI height, reproduces the symptom by construction
• tmux — partial mitigation via its decoupled buffer

Condition observed (single observation, not yet falsified). Scrollback survives when the terminal viewport is scrolled above the bottom of the buffer at the moment of an Ink redraw; destroys when the viewport is at the bottom. Consistent with microsoft/terminal#7019 grid-overwrite semantics under ConPTY.

Environments tested:

• Linux SSH (Debian 13)
• WSL2 / Ubuntu / Windows 11 (direct, no wrapper)

Practical impact on this pipeline: Claude Code interactive use has declined substantially since the 2.1.114 update. Engineering time invested in investigation and mitigation over the last two weeks has been significant. Development of Claude-Code-specific internal tooling has been paused. Alternative agent products are under evaluation; we have not observed comparable scrollback-destruction behaviour on those.

The fix point. Ink's render loop remains the primitive. ink#935 laid out three concrete options. Below that layer, emulator-by-emulator mitigation will continue to produce recurrences of this class.

Working workaround for 2.1.114 (WSL2/Win11 pipeline)

Following the earlier evidence that 2.1.114 drops CSI 3J but retains the CSI 2J + CSI H render-loop pattern, a two-part workaround now produces a usable interactive experience on this pipeline:

Part 1 — enable alt-screen via CLAUDE_CODE_NO_FLICKER=1

Puts Claude Code in alternate-screen mode. Main-buffer scrollback is preserved across the session; Claude's redraws touch only the alt buffer.

Tradeoff: Claude enables full mouse tracking (SGR mode \x1b[?1006h plus legacy 1000/1002/1003), so mouse wheel events are captured by the app instead of the terminal's native scrollback scrolling. In-app wheel handling scrolls far fewer lines per click than a typical OS setting — roughly 0.2 lines/click vs. ~3 lines/click in the tested environment — which makes wheel scroll unusably slow on its own.

Part 2 — amplify SGR wheel events on stdin

Intercept SGR wheel press sequences on the way from terminal to Claude and write each sequence N times. Effectively multiplies wheel sensitivity N-fold.

Target format (SGR mouse, mode 1006):

ESC [ < 64 ; Cx ; Cy M    (wheel-up press)
ESC [ < 65 ; Cx ; Cy M    (wheel-down press)

Only pure wheel (Cb == 64 or Cb == 65) should be amplified. Modifier-held wheel (Shift/Alt/Ctrl, Cb 68/72/80/etc.) and all non-wheel events must pass through unchanged — amplifying modifiers risks unintended behavior bound to those keys.

Implementation is roughly 150 lines of C in a small PTY-pair proxy (stdin → SGR parser → amplifier → child pty). Default amplification factor off; env-gated.

Multiplier tuning by bisect: 8 was too fast, 6 slightly fast, 4 settled as usable in the tested environment.

Result

With both parts active:

• Scrollback preserved across the session
• Wheel scroll responsive
• Click/drag UI in Claude still functional (unlike blanket CLAUDE_CODE_DISABLE_MOUSE=1, which kills those)

This is not a fix — the underlying render-loop behavior remains as described in earlier comments. It gives a functional interactive experience while the upstream question is worked out.

Remaining symptoms on this workaround

• Occasional render glitches when dynamic status/progress UI renders at viewport bottom
• Wheel speed still inconsistent in some situations (not yet characterized)

Both appear to originate in Ink's layout/redraw strategy for dynamic elements, not in the scroll-destruction mechanism. Out of scope for a terminal-side mitigation.

iTerm2 user, "tui": "default" works but flickers — please add a third mode that does alt-screen rendering but still emits lines to main-screen scrollback.

using v2.1.138 still having this problem

Any fix for this yet?

Core cause (for anyone arriving here looking for a client-side fix): Claude Code's TUI (Ink-based) enables the alternate screen buffer and performs a full-screen clear (CSI 2J + CSI H) every render. All output is painted onto the alternate screen and never written to the terminal's main buffer — so there is nothing in scrollback to recover. No client-side workaround (tmux, PgUp/PgDn, terminal shortcuts) can bring back content that was never written there in the first place. The fix has to happen upstream in the render loop.

Environment:

• Claude Code: 2.1.126
• Warp: 0.2026.05.06.15.42.04
• macOS: 26.3.1

Environment

• Claude Code 2.1.191
• macOS (Darwin 25.x), zsh

Repro

1. In a single session, spawn many sub-agents via the Task/Agent tool (I had ~16 across two batches), each returning a large result (tens of KB of text).
2. After the sub-agent outputs render, try to scroll up to re-read the main assistant's own messages.

Expected

• Able to scroll back through the full conversation, including the assistant's messages that came before/after the sub-agent output.

Actual

• Scrolling up stops at the sub-agent output/prompt region — the assistant's own messages above it are no longer reachable in the scrollback.
• A large blank gap appears between the sub-agent output and the assistant's output.

This looks like the alternate-screen-buffer scrollback regression (#42670 / #41965) combined with the large-output whitespace issue (#14683). The v2.1.191 changelog mentions scroll-position and agent-panel fixes, but the problem persists when many large sub-agent outputs accumulate in one session.

Workarounds that help but don't fix it

• Ctrl+O (transcript mode) to view full history.
• CLAUDE_CODE_NO_FLICKER=0 to disable the alternate screen buffer (restores older scrollback behavior).

I've just hit this today for the first time