vscode/terminal: terminal pane fails to refit when sibling editor group is closed (residual #1052 family)

[amrmelsayed]

Symptom

When a Codev terminal (architect or builder) shares the editor area with a second editor group and that group is then closed, the terminal pane does not re-render to fill the now-wider pane. Content stays wrapped at the old (~half) column width, the right ~half of the pane is blank, and the visible reflowed text is garbled.

Manual resize (dragging the window edge) or clear-and-reopen recovers. The PTY's COLUMNS is also stuck at the old narrow value, so a running TUI (Claude Code etc.) continues to redraw at the wrong width until the recovery action.

Repro

1. Open a Codev terminal (e.g. architect) in editor group 1
2. Open any other editor in group 2 (right side)
3. Close editor group 2
4. Observe: the terminal pane is now ~2× wider but content stays at old narrow width; right half blank; visible content garbled

Hypothesis

Same family as the recently-shipped #1052 (terminal rendering corrupted on open: replay painted at not-yet-final width), but a different trigger surface. The on-open path now correctly debounces and flushes at the settled width. Editor-group removal resizes the pane without firing that refit path: the terminal-adapter is not listening on the layout-change event that signals "your sibling group just disappeared, your width just doubled."

Proposed fix (plan-gate)

Wire the right VS Code layout-change signal into the terminal-adapter (exact event API to confirm at plan time, candidates include onDidChangeWindowState and onDidChangeActiveTextEditor plus any group-specific layout event) so editor-group changes trigger:

1. An xterm fit at the new pane dimensions (or the same buffer-and-flush settled-width approach used in vscode: terminal renders corrupted and cursor lands at top after window reactivation #1052)
2. A SIGWINCH / COLUMNS update propagated to the PTY so the TUI redraws at the right width

Same settled-width discipline as #1052 to avoid an intermediate-size repaint during the layout transition. Symmetric: opening a sibling group (terminal narrows) should hit the same path.

Acceptance criteria

• Closing a sibling editor group while a Codev terminal is open triggers a refit; content fills the new pane width
• PTY's COLUMNS matches the new pane width so the TUI redraws correctly
• Opening a sibling editor group (terminal narrows) also triggers refit, symmetric path
• No regression to vscode: terminal renders corrupted and cursor lands at top after window reactivation #1052's on-open buffer-and-flush behavior (settled-width discipline preserved)
• Manual dev-approval verification: open terminal next to a second group, close the second group, verify clean refill; reverse it, verify clean reflow
• Both architect and builder terminals exhibit the fixed behavior

Protocol selection

Surfaced by builder pir-1060 while parked at dev-approval; the builder explicitly stayed out of scope on its branch. Recommendation at spawn time:

• PIR if the architect wants visual dev-approval verification before PR. The failure mode is the exact "looks fine in unit tests, wrong on actual resize" pattern vscode: terminal renders corrupted and cursor lands at top after window reactivation #1052 went PIR to catch
• BUGFIX if the architect wants the lean version (small diff, code-only review)

Out of scope

• The on-open buffer-and-flush behavior from vscode: terminal renders corrupted and cursor lands at top after window reactivation #1052 (already shipped)
• Other terminal-pane lifecycle bugs not triggered by editor-group layout change
• The codev.terminal.repaintOnRefocus setting (orthogonal escape hatch from vscode: terminal renders corrupted and cursor lands at top after window reactivation #1052)

Related

• vscode: terminal renders corrupted and cursor lands at top after window reactivation #1052 / PR vscode: fix terminal corruption on open (render replay at the settled width) #1061: terminal renders corrupted on open (same family, different trigger surface)
• tower + vscode: terminal freeze from oversized-replay reconnect storm (unbounded no-newline buffers + client backpressure loop) #1047 / PR tower + vscode: fix terminal freeze (oversized-replay storm) and blank-on-open #1050: oversized-replay reconnect storm (independent: this is a render/refit issue, not a buffer/replay one)

Surfaced by

PIR #1060 builder during dev-approval; flagged via inter-agent messaging, kept out of scope on the builder-pir-1060 branch.

[amrmelsayed]

On it! Working on this with the PIR protocol (plan + dev-approval gates before PR).

[amrmelsayed]

Investigation update (PIR dev-approval): root cause was mis-identified; two fix attempts falsified against the running worktree

Worked this under PIR. The dev-approval gate — running the real extension in an Extension Development Host and reproducing the repro — overturned this issue's original premise. Recording what was tried and what the captured data showed, so this isn't re-attempted from the same wrong starting point.

Corrected root cause

The original hypothesis was that closing a sibling editor group resizes the pane without firing the terminal's refit path, leaving the PTY's COLUMNS stale. That is false. Instrumenting Pseudoterminal.setDimensions and the layout handler showed VS Code does re-measure the editor-area terminal on group close, and the correct width reaches the PTY:

setDimensions 70x43                       ← opened 2nd group: terminal narrowed to 70 cols
onDidChangeTabGroups closed=1 groups=1    ← closed the 2nd group
setDimensions 144x43                      ← VS Code re-measured on close (70 → 144); width propagated to the PTY

Width propagation already works. The residual symptom is xterm.js reflowing its scrollback buffer at the new width. The tool running in the pane is an inline TUI (normal screen buffer plus a bottom input box, not an alternate-screen app); on resize xterm rewraps the historical scrollback, and for content with cursor-positioning escape sequences that reflow is lossy. The result: the history renders garbled (a stranded single-character column pinned to the right edge, blanks in the middle), while the live input region stays correct. The app only ever repaints its live region — never the scrolled-back history.

Techniques tried, and why each failed

1. window.tabGroups.onDidChangeTabGroups (gated to opened/closed) → terminal.show(true) on editor-area terminals. Intent: coax VS Code into re-measuring the widened pane. Result: no effect. show() on an already-visible terminal is a no-op for re-layout, and the log shows setDimensions had already fired (correctly) before the show() ran. Redundant with behavior that already happens.

2. Same trigger → pty.forceRepaint() — a SIGWINCH nudge at the now-correct width (the same lever the vscode: terminal renders corrupted and cursor lands at top after window reactivation #1052 refocus path and a manual window-edge drag use). Intent: force one clean redraw after the layout settles. Result: no effect. The log confirms it fired at the right width (forceRepaint nudge at 144x43) and the history stayed garbled — because a SIGWINCH only makes the app repaint its live region; nothing repaints xterm's already-reflowed scrollback.

Both attempts were verified against the running worktree, not just unit tests.

Why this isn't fixable from the extension (non-destructively)

A Pseudoterminal-backed terminal gives the extension no handle on the xterm.js instance or its buffer. There is no public VS Code setting or API to disable reflow or force a clean re-render of historical scrollback. On the xterm side, reflowCursorLine only affects the cursor line, refresh() only the current viewport, and clear() / reset() are destructive (they lose history). The only non-destructive route would be architectural — maintain our own scrollback model and render to a custom surface — which is disproportionate and out of scope. An external-model consultation corroborated this reading of the public API surface.

Upstream status (for context)

• Runtime base here is Cursor's bundled VS Code 1.105.1; upstream VS Code latest is 1.125.0.
• No merged VS Code PR in the 1.106 → 1.125 window targets this macOS editor-area reflow case. The recent "terminal output messed up when resizing" reports (microsoft/vscode#287761, microsoft/vscode#285671, microsoft/vscode#230852) are all Windows / ConPTY and were closed as duplicates of microsoft/vscode#224488 ("Ship newer version of conpty", milestone 1.121) — a different code path that does not apply on macOS.
• The underlying behavior is long-standing xterm reflow (microsoft/vscode#172281, microsoft/vscode#23688), not a regression with a pending fix.

Recommended disposition

• Do not merge an extension-side fix — both levers are no-ops against the real cause.
• One definitive check remains: reproduce in stable VS Code 1.125 (not Cursor). If clean there, it's already fixed upstream and will resolve when Cursor rebases its VS Code base; if still garbled, it's a known upstream xterm reflow limitation we can't address from the extension.
• The experimental branch changes (the show() / forceRepaint() wiring and the diagnostics) will be reverted so the branch is clean.