[BUG] Terminal rendering corruption (stale/duplicated frames) on Windows — Agent View transitions, scrolling, long sessions
Environment
- Claude Code: v2.1.215 (latest at time of filing)
- OS: Windows 11 (native, PowerShell/Git Bash — not WSL)
- Terminal: Windows Terminal
CLAUDE_CODE_ALT_SCREEN_FULL_REPAINT=1set (did not prevent the bug)
Description
Terminal rendering becomes corrupted — stale text/UI fragments bleed through, prompt/status bar duplicates stacked, mid-word wrapping — after normal interactive use. Only a full window resize (forces a complete redraw) clears it, and only until the next trigger. A full close-all-terminals + relaunch (claude --continue) resets it for a while but it recurs.
Triggers observed (multiple, not one single cause)
- Switching into/out of Agent View (
claude agents, or←on empty prompt) — most reliable trigger. - Attaching into a session from Agent View.
- Occurred once with no Agent View involvement at all — best guess was scrolling during a long session with heavy output.
What was ruled out
CLAUDE_CODE_ALT_SCREEN_FULL_REPAINT=1alone — tried across a clean full-process restart, did not prevent recurrence.CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1(alone and combined with the above) — did not prevent recurrence, and per #76349 may actively worsen this class of bug.Ctrl+L— does not force a clean redraw (matches #65593's finding on WSL2, unlike #76349 where it reportedly worked for some).- Switching terminal emulators would not be expected to help — per #78890's analysis this looks like a bug in what Claude Code emits, not in terminal interpretation.
Likely root cause
This looks like the same underlying issue described in #78890: the differential renderer sometimes emits CUF (cursor-forward, a non-destructive move) instead of writing real space/blank characters during incremental repaints. Since CUF doesn't clear the cell it skips over, stale content from a previous frame remains visible underneath. That would explain:
- Why a full resize fixes it (forces a full redraw that writes real cells).
- Why env vars around alt-screen mode don't help (they don't touch this incremental-diff code path).
- Why it can be triggered by several different UI transitions (Agent View switch, scrolling, long output) rather than one specific action — any incremental repaint over previously-drawn content can hit it.
Related issues
- #78890 — differential renderer CUF-vs-space root cause analysis (best technical match)
- #76349 — Agent View/FleetView ↔ REPL ghosting with alt-screen disabled (matches the Agent View trigger path)
- #65593 — Agents view stale/garbled frame until resize, WSL2 (matches Ctrl+L-does-not-help finding)
- #69577 — spinner/status frames leak into scrollback via cursor-up rewind clamp (matches the no-Agent-View, scrolling-triggered case)
Screenshot
Have a screenshot showing the duplicated/stacked prompt bar and mid-word wrapping from a live repro — happy to attach if useful, just say the word.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Confirming this on a second machine — same exact profile as OP:
"tui": "fullscreen"setCLAUDE_CODE_ALT_SCREEN_FULL_REPAINT=1set in profile, persisted across sessions — does not prevent the corruptionMost reliable trigger for me is also switching into/out of Agent View. A full window resize is still the only thing that clears it. Adding this for visibility/prioritization — happy to provide more repro detail if useful.
Still reproducing on v2.1.236 (current latest on npm), roughly a month after this was filed. Adding a fresh data point plus a correlation that may sharpen the repro.
Environment
cmd.exeprofile, stocksettings.json(no custom renderer/experimental flags — ruling out local config)CLAUDE_CODE_ALT_SCREEN_*env vars setSymptom
Same trigger as the OP: navigating between chats inside Agent View / FleetView. The failure mode here is specifically a whole-frame duplicate — the agent list renders a second complete copy below the stale one (separator bar and all), and everything below the footer stays black until a manual window resize. It is not subtle single-cell bleed; it's the entire list drawn twice.
Possible correlation: list length vs. viewport height
The fleet had 65 entries in
~/.claude/jobs, so the list frame was considerably taller than the terminal viewport. That is exactly the condition where an incremental repaint has to erase more rows than exist on screen, and it lines up with #81910 ("above a window-size threshold"). Consistent with the CUF-vs-space analysis in #78890: any repaint that walks over previously-drawn content can hit it, but a frame that overflows the viewport makes it near-deterministic rather than occasional.Currently testing whether trimming the fleet to 24 entries (frame fits the viewport) reduces the frequency, and will report back.
Confirmations
Ctrl+Ldoes nothing here either — matches the OP.Ctrl+-thenCtrl+0(nudge font size down, reset to default) fires the same resize event as dragging the window, so the workaround doesn't require the mouse.Reporting back, and correcting my previous comment — my "still reproducing on v2.1.236" claim was imprecise in a way that matters for triage.
claude --versionreported 2.1.236, but the running Agent View process was older. CheckingcliVersionin~/.claude/jobs/<id>/state.jsonacross the fleet at the time of the repro shows the sessions were actually executing 2.1.220, 2.1.233, 2.1.234 and 2.1.235 — an updated binary does not reload an already-running session. So the render fixes shipped in 2.1.236 were installed but never actually loaded when the corruption occurred.After updating to 2.1.237 — which carries no render changes itself (just prompt caching over gateways and a new output style), but does restart the process onto 2.1.236+ code — the duplicated-frame corruption has not reappeared in Agent View navigation.
The 2.1.236 entry most likely to be responsible is "Fixed the
/modelpicker rendering taller than the terminal: it now shows only as many models as fit the window, with the rest reachable by scrolling" — same failure class as this issue: a frame taller than the viewport being incrementally repainted.Caveat, stated plainly: two variables changed at once. I had also trimmed the fleet from 65 entries down to ~25, so the list frame now fits the viewport regardless. I cannot isolate which one fixed it, and I would not close this on my report alone.
Suggestion for anyone else triaging this class of report: compare
cliVersionin~/.claude/jobs/<id>/state.jsonagainstclaude --versionbefore filing. If they diverge, restart first — the fix may already be installed but not running.