TL;DR Type
/tui. If it answersCurrent renderer: default, you're on the classic renderer, the one that flickers: run/tui fullscreenand Claude Code relaunches in the flicker-free renderer with your conversation intact. To search the conversation afterwards, pressCtrl+o, then/.
If Claude Code's screen flashes while tool output streams in, or your terminal jumps back to the top of the scrollback while Claude is working, you're on the classic renderer. Claude Code has two ways of drawing its interface. The classic one writes to the terminal's normal screen, the one with the scrollback, and sends it a lot of text on every update. Fullscreen draws on the alternate screen buffer, like vim or htop, and only renders the messages you can see: less data per update, no flicker, and flat memory however long the conversation gets.
You notice it most where the bottleneck is how fast the terminal can paint: the VS Code integrated terminal, tmux and iTerm2. "Fullscreen" has nothing to do with maximizing the window; it works at any size.
Which one you're on
Not everyone starts in the same place. If you first used Claude Code on or after May 6, 2026, you're most likely on fullscreen already; an older install stays on classic unless you switched. /tui with no argument tells you. This is the answer in Claude Code v2.1.310, in a test session with an empty configuration:
❯ /tui
⎿ Current renderer: default. Usage: /tui <default|fullscreen>
default is classic. A few setups keep you on classic even on a new install:
| Your setup | Renderer |
|---|---|
CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 or CLAUDE_CODE_NO_FLICKER=0 is set |
Classic |
| A fullscreen start failed on this machine | Classic, and it says so at startup |
iTerm2's tmux -CC integration, or SSH into Claude Code running on Windows |
Classic |
| Screen reader mode | Classic, except in background sessions |
When a failed start is the reason, the Current renderer line says so in parentheses; the "Unrecoverable interface error" tip covers that case.
How to switch
1. Run /tui fullscreen inside the session
❯ /tui fullscreen
Claude Code saves the setting and relaunches. When it comes back, it confirms:
✔ Using flicker-free rendering · if you want to go back, use /tui default
· Click to move your cursor in the text input
· Click to expand collapsed tool results
· By default, text auto-copies when you select it (/config to change)
· Hold Shift (Option in iTerm2, Fn in Terminal.app) while selecting to use your terminal's native copy instead
The conversation is still on screen, along with your permission mode, effort level and the model you picked with /model. The switch lands in your ~/.claude/settings.json, so later sessions start in fullscreen too:
{
"tui": "fullscreen"
}
2. If it says "Cannot switch renderers in this session"
Claude Code refuses to relaunch when the session has something it can't hand to the new process: a --system-prompt replacing the built-in one, a --tools allowlist, --setting-sources, or deny or ask rules a hook added for that session only. With --setting-sources it answers this and changes nothing:
⎿ Cannot switch renderers in this session — it has restrictions a restart can't carry over (launch flags: a custom
system prompt, a tool allowlist, or restricted settings). Nothing was changed. Running /tui default in a session
started without them switches every later session too.
Then run /tui fullscreen in a regular session, or start this one with the variable, which overrides the saved setting:
CLAUDE_CODE_NO_FLICKER=1 claude
With "tui": "default" saved and the variable set to 1, /tui answers Current renderer: fullscreen.
3. On tmux, turn on mouse mode
Without tmux's mouse mode, the wheel goes to tmux instead of Claude Code. Claude Code detects it and tells you:
tmux detected · scroll with PgUp/PgDn · or add 'set -g mouse on' to ~/.tmux.conf for wheel scroll
Add the line to ~/.tmux.conf and reload your config:
set -g mouse on
tmux releases through the 3.6 series don't implement synchronized output, so some flicker can remain on redraws inside tmux. If you see it, upgrade tmux or run Claude Code in its own terminal tab. And never turn fullscreen on under tmux -CC: the wheel does nothing and a double-click can corrupt the terminal state.
What changes
The conversation no longer lives in your terminal's scrollback but on the alternate screen. The prompt stays pinned to the bottom while the answer streams: if it doesn't move, fullscreen is on. Three habits change:
| Before | In fullscreen |
|---|---|
Cmd+f or tmux search |
Ctrl+o for transcript mode, then / to search, n and N to jump |
| Select and copy with the terminal | Claude Code owns the selection and copies on mouse release; hold Shift (Option in iTerm2, Fn in Terminal.app) to select with the terminal |
| Scroll with the terminal | PgUp and PgDn, the wheel, and Ctrl+End to get back to the bottom |
When you need the text in the real scrollback, press Ctrl+o, then [: it writes the whole conversation to your terminal, everything expanded, until you leave with Esc or q. If mouse capture is what bothers you, CLAUDE_CODE_DISABLE_MOUSE=1 gives you native selection back and keeps the flicker-free renderer.
In Windows Terminal, fragments of old text can stay on screen until you resize the window; CLAUDE_CODE_ALT_SCREEN_FULL_REPAINT=1 repaints every cell on every frame. And if the display looks garbled, Ctrl+L redraws it without losing anything.
Going back to classic
Fullscreen is still a research preview. /tui default takes you back to classic and, before relaunching, may ask why:
Fullscreen feedback
To help us make fullscreen mode better, what made you switch back?
>
Enter to send · Esc to skip
Esc skips it and the setting goes back to "tui": "default". To force classic for a single session without touching the setting, CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 claude.
With fullscreen on, /diff also opens the diff panel beside the conversation. And if what you notice isn't flicker but a session that slows down or eats your RAM, the fix list for a slow Claude Code starts somewhere else.
Official docs: Fullscreen rendering