What fullscreen rendering is
Claude Code has two renderers. The classic one prints to your terminal the way any CLI does, so the conversation ends up in native scrollback. The fullscreen renderer draws to the terminal's alternate screen buffer instead, the same surface vim and htop use, and paints only the messages currently on screen.
Three things follow from that. Flicker disappears, because far less data goes to the terminal on each update. Memory stays flat no matter how long the conversation runs, because only visible messages are kept in the render tree. And the mouse works: clicking, dragging, scrolling and expanding tool output all happen inside Claude Code.
One naming point that trips people up immediately, and which Anthropic's own fullscreen documentation calls out: "fullscreen" describes how Claude Code takes over the terminal's drawing surface. It has nothing to do with maximising your terminal window, and it works at any window size.
It is a research preview as of August 2026. It has been tested on common terminal emulators, but unusual configurations can still hit rendering problems.
The news hook: Bedrock, Vertex and Foundry just got it
If you use Claude Code through a cloud provider rather than a direct Anthropic login, you may only have met this feature in the last few days. Claude Code v2.1.239, released 21 August 2026, added, in the changelog's own words, "the one-time fullscreen renderer offer on Bedrock, Vertex, Foundry and other previously excluded setups; new installs there now start in fullscreen."
The reason those setups were excluded is worth understanding, because it explains a whole class of Claude Code behaviour. Sessions through Amazon Bedrock, Google Cloud's Agent Platform or Microsoft Foundry do not fetch feature flags from Anthropic, and neither do sessions with telemetry turned off. Feature-flag fetching was what drove the fullscreen-by-default rollout, so those users sat in the "anything else" row of the table and got the classic renderer indefinitely. v2.1.239 gave them their own path in.
Which renderer you start in
Anthropic documents this as an ordered table, first match wins. Attached background sessions always render fullscreen, and screen reader mode always uses the classic renderer, before any of this applies.
| Your situation | Renderer you start in |
|---|---|
CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 or CLAUDE_CODE_NO_FLICKER=0 | Classic |
CLAUDE_CODE_NO_FLICKER=1 | Fullscreen |
| Fullscreen was turned off after a failed start on this machine | Classic |
iTerm2's tmux -CC integration mode, or SSH to Claude Code on Windows | Classic |
You saved a tui setting | Whichever the setting names |
| No feature flags, and Claude Code stopped offering the startup dialog here | Classic |
| No feature flags, and this machine's first launch ran v2.1.239 or later | Fullscreen |
| Feature flags on, and you first used Claude Code on or after 6 May 2026 | Fullscreen |
| Anything else | Classic |
That eighth row is the one v2.1.239 added. It is scoped to a machine's first Claude Code launch, so an existing install on Bedrock does not silently flip; it gets the one-time offer dialog instead.
How to switch renderers
Inside any conversation:
/tui fullscreen
Claude Code saves the tui setting and relaunches into fullscreen with your conversation intact, so you can switch mid-session without losing context. /tui default goes back. /tui with no argument prints which renderer is active and, if a failed start is the reason you are in classic, says so.
Or set the environment variable before launching:
CLAUDE_CODE_NO_FLICKER=1 claude
Claude Code carries a specific list of things into the relaunched session: the conversation as it appears on screen, your permission mode and effort level, the model you last picked with /model, and any --allowed-tools, --disallowed-tools, --agent, --agents or --append-system-prompt flags.
It refuses to relaunch when a session has a restriction it cannot pass to the restarted process. That includes a --system-prompt replacement, a --tools allowlist, --setting-sources, and deny or ask rules that a hook or SDK permission update added for this session only. In that case you get Cannot switch renderers in this session with the reasons, and nothing changes.
One interaction with /rewind is worth knowing: the relaunch takes the conversation as it appears on screen, not the longer transcript on disk. Rewind past your last three messages and then switch renderers, and the relaunched session opens without them. Rewind to before your first message and you relaunch with an empty conversation.
What changes day to day
The input box stays fixed at the bottom instead of moving as output streams in. That is the quickest way to tell which renderer you are in: if the input does not move while Claude works, fullscreen is active.
Because the conversation lives in the alternate screen buffer rather than scrollback, three habits break:
| Before | Now |
|---|---|
Cmd+f or tmux search to find text | Ctrl+o for transcript mode, then / to search or [ to write to scrollback |
| Terminal click-and-drag to select and copy | In-app selection, copies automatically on mouse release |
Cmd-click to open a URL | Cmd-click on macOS, Ctrl-click elsewhere |
Searching and reviewing the conversation
Ctrl+o toggles transcript mode, which gains less-style navigation:
| Key | Action |
|---|---|
/ | Open search. Enter accepts, Esc cancels and restores scroll position |
n / N | Next or previous match, even after closing the search bar |
j / k or ↑ / ↓ | Scroll one line |
g / G or Home / End | Jump to top or bottom |
{ / } | Jump to the previous or next prompt |
Ctrl+u / Ctrl+d | Scroll half a page |
Ctrl+o, Esc, or q | Exit transcript mode |
Two escape hatches from transcript mode hand the content back to your terminal. Pressing [ writes the full conversation into native scrollback with all tool output expanded, so Cmd+f and tmux copy mode can search it again; that lasts until you exit transcript mode. Pressing v writes the conversation to a temporary file and opens it in $VISUAL or $EDITOR.
There is also /focus, which shows only your last prompt, a one-line summary of tool calls with edit diffstats, and the final response. The setting persists across sessions.
Scrolling
| Shortcut | Action |
|---|---|
PgUp / PgDn | Scroll half a screen |
Ctrl+Home | Jump to the start of the conversation |
Ctrl+End | Jump to the latest message and re-enable auto-follow |
| Mouse wheel | Scroll a few lines |
A genuinely useful side effect: you can scroll back to the start of a session even after compaction. Claude continues from the compaction summary, but the fullscreen scrollback keeps every earlier message across repeated compactions.
Scrolling up pauses auto-follow, and a floating Jump to bottom button appears with a count such as 3 new messages. On MacBook keyboards there is no working jump-to-bottom chord by default, because Ctrl+Fn+→ does not reach Claude Code on macOS. Use the button, scroll to the bottom with the wheel, or rebind scroll:bottom to a chord your keyboard can actually send. Our keybindings guide covers how rebinding works.
If wheel scrolling feels sluggish, your terminal is probably sending one event per notch with no multiplier, which is what the VS Code integrated terminal does:
export CLAUDE_CODE_SCROLL_SPEED=3
3 matches vim's default. The setting accepts any positive value up to 20, including fractional values below 1 such as 0.25 to slow down terminals that already amplify wheel events. /scroll-speed opens an interactive dialog with a scrollable ruler so you can feel the change; it steps in whole numbers up to 10, with quarter steps on terminals that support finer control (v2.1.172 or later). The dialog writes the same value to ~/.claude/settings.json, and it is unavailable in the JetBrains IDE terminal.
The mouse capture trade-off
This is the friction point, especially over SSH or inside tmux. When Claude Code captures mouse events, your terminal's native copy-on-select stops working. The selection you drag exists inside Claude Code, not in your terminal's selection buffer, so tmux copy mode and similar tools do not see it.
Claude Code compensates by writing the selection to your system clipboard, through pbcopy on macOS, wl-copy or xclip or xsel on Linux, and PowerShell Set-Clipboard on Windows and WSL. Inside tmux it also writes the tmux paste buffer; over SSH it falls back to OSC 52 escape sequences. A toast after each copy tells you which path it used. Some terminals block OSC 52 by default, iTerm2 among them, until you enable Settings, then General, then Selection, then "Applications in terminal may access clipboard"; running /terminal-setup in iTerm2 does this for you.
For a one-off native selection, hold a modifier while dragging: Fn in Terminal.app, Option in iTerm2, Shift in VS Code, Cursor and most other terminals.
If you rely on native selection constantly, opt out:
CLAUDE_CODE_NO_FLICKER=1 CLAUDE_CODE_DISABLE_MOUSE=1 claude
You keep flicker-free rendering and flat memory, and you lose click-to-position-cursor, click-to-expand, URL clicking and wheel scrolling inside Claude Code. Keyboard scrolling still works.
CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 is the middle ground, added in v2.1.195: the wheel and touchpad still scroll, left clicks do nothing inside Claude Code. CLAUDE_CODE_DISABLE_MOUSE takes precedence when both are set.
Running it under tmux
Fullscreen works in tmux with three caveats.
Wheel scrolling needs tmux's mouse mode. Without it, wheel events go to tmux rather than Claude Code:
set -g mouse on
Claude Code prints a one-time hint at startup if it detects tmux with mouse mode off. Keyboard scrolling with PgUp and PgDn works either way.
Fullscreen is incompatible with iTerm2's tmux integration mode, meaning tmux -CC. In integration mode iTerm2 renders each pane as a native split rather than letting tmux draw, so the alternate screen buffer and mouse tracking misbehave: the wheel does nothing and double-click can corrupt terminal state. Regular tmux inside iTerm2, without -CC, is fine.
Finally, tmux releases through the 3.6 series do not implement synchronised output, so you may see more flicker under those versions than running Claude Code directly. Upgrade tmux, or run Claude Code in its own tab outside tmux.
Does this affect Agent Skills?
No, and it is worth saying so plainly since that is this site's subject. Fullscreen rendering is a rendering path. It changes how the CLI draws to your terminal and nothing about how Agent Skills are discovered, loaded or executed. Skills in ~/.claude/skills/ and .claude/skills/ behave identically in both renderers, and progressive disclosure is unaffected.
The one practical connection is comfort at scale. Click-to-expand on a collapsed tool result makes reviewing what a skill actually did considerably faster than scrolling past truncated output, which matters if you are working through the kind of skill that runs bundled scripts. That is a workflow improvement, not a behaviour change.
Troubleshooting
Stale or misplaced text on screen. Fullscreen sends only the cells that changed between frames, and some terminals, most commonly Windows Terminal and other ConPTY-backed hosts, coalesce those positioned writes incorrectly and leave fragments behind until you resize. Set CLAUDE_CODE_ALT_SCREEN_FULL_REPAINT=1 to repaint every cell on every frame:
CLAUDE_CODE_ALT_SCREEN_FULL_REPAINT=1 claude
On Windows, Claude Code already enables full repaint automatically for background sessions and agent view, so you only need this for an interactive fullscreen session you launched yourself.
"Claude Code's fullscreen renderer didn't finish starting last time". A fullscreen session on this machine crashed before starting successfully, and a session counts as successful once it has drawn its first frame and then either stayed up for 10 seconds or been ended with /exit, Ctrl+C or Ctrl+D. After one failed start you see that line and Claude Code retries fullscreen next session. After two, you see "has repeatedly failed to start on this machine" and it keeps using classic until you update Claude Code or run /tui fullscreen yourself. Failed starts are counted per Claude Code version, and a successful start resets the count. Before v2.1.236, Claude Code kept starting in fullscreen after a failed start regardless.
Mouse wheel does nothing but PgUp and PgDn work. In iTerm2, mouse reporting is a per-profile setting. Open Settings, then Profiles, then Terminal, and turn on "Enable mouse reporting". The same setting gates click-to-expand and text selection.
Scrolling is wild in the JetBrains IDE terminal. Claude Code applies its own scroll handling there and ignores CLAUDE_CODE_SCROLL_SPEED, because that terminal emits events at a far higher rate than other emulators. In JetBrains 2025.2 the terminal also has scroll-wheel bugs producing spurious arrow keys and wrong-direction events; Claude Code detects and mitigates them at runtime. Upgrading to 2025.3 or later is the real fix.
Ctrl+L or Cmd+K no longer clears the conversation. That changed in v2.1.238. Claude Code redraws the screen and keeps the conversation. Use /clear to start fresh. On iTerm2 and Terminal.app, Cmd+K is handled by the terminal itself, which clears its own screen without telling Claude Code; Claude Code detects the cleared screen and repaints.
You want to force classic regardless of the saved setting. Set CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1. This overrides the tui setting rather than changing it.
Where to go next
Anthropic's fullscreen rendering page is the primary reference and covers a few edge cases this piece skips, including exact selection-key behaviour. For the keyboard side of the same surface, see our Claude Code keybindings guide, and for what else shipped around it, Claude Code output styles explained covers the Concise style added the day before. If you are running Claude Code unattended rather than interactively, where none of this applies, Routines vs /loop and self-hosted runners are the relevant pieces. Install paths for skills on every platform are at /platforms/claude-code.
Verified 24 August 2026 directly against code.claude.com's fullscreen rendering documentation and the v2.1.239 changelog entry dated 21 August 2026.
