Short answers to what readers ask most about this topic.
Fullscreen rendering kills flicker and flattens memory by drawing on the alternate screen. That costs you native scrollback and mouse selection, and both are recoverable.
Matthews Wong
Software Engineer
Key Takeaway
Fullscreen rendering draws Claude Code on the terminal's alternate screen buffer, the way vim does, and renders only the messages currently visible. Flicker disappears and memory stays flat regardless of conversation length. The cost is that your terminal's native search and selection no longer see the conversation, because it is no longer in the scrollback.
I switched to fullscreen rendering because my scroll position kept jumping to the top while Claude worked, and it fixed that completely on the first try. Then I went to search the conversation with my terminal's find, and there was nothing to find. The conversation was still there — it just was not in a place my terminal could see any more.
That trade is the whole story of this mode, and both halves of it are recoverable if you know the escape hatches. This post covers what fullscreen actually changes, how you end up in it without choosing, the transcript-mode keys that hand the conversation back to your terminal, the three levels of opting out of mouse capture, and the failed-start counter that quietly returns you to the classic renderer.
Fullscreen is a different rendering path, not a window mode — the name describes taking over the terminal's drawing surface the way vim does, and it works at any window size. It draws on the alternate screen buffer and keeps only visible messages in the render tree, which is why memory stays constant however long the conversation gets and why the amount of data sent to your terminal per update drops sharply.
The difference is most visible where rendering throughput is the bottleneck: the VS Code integrated terminal, tmux, and iTerm2. The quickest way to tell which renderer you are in is the input box — if it stays fixed at the bottom while Claude works rather than moving as output streams in, fullscreen is active.
You can switch mid-session and keep the conversation, because Claude Code relaunches and carries the session state across. What it carries is specific, and so is what stops it.
# Switch mid-session. Claude Code saves the tui setting and
# RELAUNCHES with your conversation intact.
/tui fullscreen
/tui default
/tui # print which renderer is active, and why
# Or before launch:
CLAUDE_CODE_NO_FLICKER=1 claude
# It carries over: the conversation as it appears on screen,
# your permission mode, effort level, the model you last picked,
# and your allowed-tools, agent and append-system-prompt flags.
#
# It REFUSES to relaunch when the session holds a restriction it
# cannot pass on — a --system-prompt replacement, a --tools
# allowlist, --setting-sources, or deny/ask rules a hook added
# for this session only. It prints the reasons and changes
# nothing.The relaunch carries the conversation as it appears on screen, which matters after a rewind. If you rewound past your last three messages, the relaunched session opens without them — the longer transcript on disk is not what comes back. Rewind to before your first message and you relaunch with an empty conversation. Worth knowing before you switch renderers to tidy up a session you have just rewound.
This is the part people give up on too early. The conversation is not lost, it is in a buffer your terminal's search cannot reach — and there is a single key that hands it back.
Three things that work differently, and the replacement for each:
| Before | In fullscreen | Note |
|---|---|---|
| Terminal find or tmux search | Transcript mode, then slash to search | Or the bracket key to write it all into native scrollback |
| Native click-and-drag selection | In-app selection, copied on mouse release | Hold your terminal's modifier for a one-off native selection |
| Modifier-click to open a URL | Command-click on macOS, Control-click elsewhere | A plain click deliberately does not open links |
# The conversation lives in the alternate screen buffer, so
# your terminal's own search cannot see it. The way back:
Ctrl+O toggle transcript mode
/ open search; Enter accepts, Esc restores position
n / N next / previous match, even after closing search
{ / } jump to the previous / next PROMPT
g / G top / bottom
[ write the WHOLE conversation into your terminal's
native scrollback, tool output expanded. Now Cmd+F
and tmux copy mode work on it. Lasts until you exit
transcript mode.
v write it to a temp file and open $VISUAL or $EDITOR
/focus a quieter view: your last prompt, one line per tool
call with edit diffstats, and the final response.
Persists across sessions.
# You can scroll back past compaction. Claude works from the
# summary, but fullscreen keeps every earlier message in its
# own scrollback across repeated compactions.Mouse capture is the most common friction point, especially over SSH or inside tmux, because your terminal's copy-on-select stops working — the selection lives inside Claude Code rather than in the terminal's selection buffer. There are three levels of opting out, and most people reach for the biggest one when a smaller one would do.
# Mouse capture is the most common friction point, especially
# over SSH or in tmux. Three levels of opting out:
# 1. Keep everything, copy manually instead of on select:
# toggle "Copy on select" off in /config
# 2. Keep wheel scrolling, drop click/drag/hover:
CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1
# 3. Give the mouse back to the terminal entirely, keeping the
# flicker-free rendering and flat memory:
CLAUDE_CODE_DISABLE_MOUSE=1
# For a ONE-OFF native selection, hold your terminal's key:
# Terminal.app Fn
# iTerm2 Option
# VS Code and Cursor Shift (or Option on macOS with
# macOptionClickForcesSelection on)
# most others Shift
# Scroll feels slow? Some terminals send one event per notch
# with no multiplier. VS Code's terminal is one of them.
export CLAUDE_CODE_SCROLL_SPEED=3 # 3 matches vim's default
# Or run /scroll-speed for a live ruler you can feel.Claude Code does write the selection to your system clipboard, using whichever path fits your setup: the native clipboard tool locally, the tmux paste buffer inside tmux, and terminal escape sequences over SSH. It prints a toast after each copy naming the path it used, which is the fastest way to find out that your terminal is blocking the escape-sequence path — iTerm2 does by default until you enable clipboard access, and the terminal-setup command turns that on for you.
Fullscreen works inside tmux, and each of these will look like a bug if you do not know about it:
If you see stale fragments of earlier output on screen until you resize the window, that is a terminal coalescing incremental writes incorrectly — Windows Terminal and other ConPTY-backed hosts most often. There is an environment variable that repaints every cell on every frame instead of sending incremental updates, which fixes it at some cost in throughput.
If a fullscreen session crashes before it has started successfully, Claude Code puts your next session in the classic renderer and tells you so. A session counts as having started successfully once it has drawn its first frame and then either stayed up for ten seconds or been ended deliberately. After one failed start it tries fullscreen again next time; after two, it stays on the classic renderer until you update Claude Code or ask for fullscreen explicitly.
That is worth knowing because the second state prints nothing in later sessions — you are simply in the classic renderer with no explanation on screen. Running the tui command with no argument tells you which renderer is active and, while a failed start is the reason, says so on the current-renderer line. It is the difference between a five-second answer and a confused afternoon.
Three questions settle it, in this order:
Fullscreen is a research preview and behaves like a good one: it solves a specific, annoying problem completely, and it is honest about what it costs. The two keys that made it stick for me were the transcript toggle and the bracket key that writes everything back into native scrollback — with those, nothing is actually lost, it is just one keystroke further away than it used to be. If flicker is not bothering you, there is no reason to switch.
Sources & further reading