[BUG] VS Code: TUI input box left as stale cells after adding a folder to the workspace mid-session
Summary
Adding a folder to the VS Code workspace while Claude Code is working corrupts the TUI input box. The transcript and status line keep rendering correctly, but the composer region is replaced by leftover glyphs from earlier frames plus a solid highlighted block. The session keeps running normally and finishes its task; only the input area is unusable. Opening a new session forces a full redraw and clears it.
Environment
- Claude Code CLI: 2.1.217
- VS Code extension:
anthropic.claude-code-2.1.120-win32-x64 - VS Code: 3.12.10 (
24a12dbd9cabf48956ce5bb3dbd234e41385b3d0, x64) - OS: Windows 11 Home 10.0.26200 (ConPTY)
Steps to reproduce
- Open a single-folder workspace in VS Code.
- In the Claude Code panel, start a prompt that runs a while (multi-file edit / long tool run).
- While it is still working,
File > Add Folder to Workspace…and pick any second folder. - Watch the panel relayout.
Expected
The relayout triggers a full repaint; the input box redraws intact.
Actual
Above the input box everything is correct — tool lines and the * Topsy-turvying… (3m 56s · ↓ 15.0k tokens) status line render normally. The input box itself does not repaint. In its place: orphaned characters at scattered columns (ii [], a lone d, f, ⌐ it) and a solid cyan cell-run on the right. Screenshot attached.
Impact
Low, cosmetic but blocking for that session. The backend is unaffected: the in-flight task ran to completion and file edits landed. No data loss. But there is no usable prompt, so the session cannot be continued or interrupted from the UI.
Workaround
Start a new session (full redraw restores the input box). Opening the second folder in a separate VS Code window avoids the trigger entirely.
Possibly related
Looks like the same stale-cell family as #78890 — the differential renderer skipping cells with CUF instead of writing spaces, so non-blank → blank transitions leave old content behind. Worth noting the inversion: in #78890 a terminal resize repairs the corruption by forcing a full redraw, whereas here the panel resize is what produces it, which would point at the post-SIGWINCH diff being taken against a frame buffer still sized for the old dimensions.
Also adjacent: #46834 (SIGWINCH relayout spills transcript into scrollback), #65593 (stale frame persists until resize), #68268 (Windows stale-cell bottom chrome, closed as dup).