[Bug]: Right-panel terminal does not re-fit on resize - cursor lands in the wrong column and typed text draws over the prompt

[martin-ptsoft]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Open a thread and open a terminal in the right side panel.
2. Let a prompt render at the panel's current width.
3. Drag the panel divider to resize the terminal. It does not always reproduce on the first drag - dragging the panel narrower than its starting width is the reliable trigger.
4. Start typing at the prompt.

Expected behavior

After the panel is resized, the terminal recomputes its columns and rows, tells the PTY the new dimensions, and reflows. The cursor sits immediately after the shell prompt, and typed characters appear there.

Actual behavior

The terminal keeps the column count it had before the drag. The shell still believes it has the old width, so the cursor is placed at the wrong column - typed text is drawn on top of / "behind" the prompt path instead of after it. In the attached screenshot the caret sits several characters into the ...t3code-6b302549$ prompt rather than after it.

Line editing is affected too: backspace, arrow keys, and history recall redraw at the wrong offset, so the visible line stops matching what the shell actually has in its buffer.

This looks like the same class of bug as #4842 ("Terminal drawer does not re-fit when its container is resized"), which was fixed for the bottom terminal drawer by #4860. The right side panel terminal appears to still miss the resize.

Impact

Minor bug or occasional failure

Version or commit

0.0.42 (stable channel)

Environment

T3 Code client 0.0.42 on macOS 27. Server: T3 Code 0.0.42, Ubuntu 26.04.1 LTS, Linux 7.0.0-31-generic x86_64, Node v24.19.0, Bun 1.4.2. Shell: bash

Logs or stack traces

none - purely a rendering/size-negotiation problem, nothing logged

Screenshots, recordings, or supporting files

Screen.Recording.2026-09-16.at.10.39.39.mov

Workaround

Close and reopen the terminal, or run clear / press Ctrl+L after resizing - the shell redraws at the correct width once it learns the new size.

[juliusmarminge]

Triage

Confirmed on current main (ccf220be2) and shipping 0.0.42. This is a real web/desktop terminal sizing bug, not a wash of #4842 / #4860 / #11923. #4842 was the bottom drawer never observing its container; #4860 replaced xterm with Ghostty and closed that. The right-panel terminal still misses the width path: the panel divider changes an ancestor’s pixel width, and that never bumps the drawer’s refit epoch, while Ghostty tells the PTY only after a 150ms settle. Narrowing a long bash prompt is the reliable demo — the caret lands inside …t3code-6b302549$ and typed text overwrites the path.

Both surfaces mount the same ThreadTerminalDrawer → TerminalViewport → GhosttyTerminalSurface. The panel is mode="panel" with height={0} (PersistentThreadTerminalPanel). clampDrawerHeight(0) becomes 180px and never moves. The drawer’s extra refit effect only depends on drawerHeight and resizeEpoch. resizeEpoch advances on drawer-height drag end, window resize, and visibility. The panel hides that height handle. Width lives in PreviewPanelShell / useResizableWidth (t3code:preview-panel-width:<thread>). Drag updates the host width: Npx and the inner calc(Npx - 1px). Nothing in that chain calls setResizeEpoch.

Ghostty does observe the mount (ResizeObserver → fit()). fit() reflows the local grid in the same frame, then notifyResize() waits 150ms before onResize → terminal.resize RPC. That is the mismatch the recording shows. After a narrower drag, Ghostty is already on the new column count; bash / readline still have the old COLUMNS until SIGWINCH lands and the line is reprinted. A long \w prompt then places the cursor several cells into the path. First-drag flakes match the race (wait out the timer and bash’s WINCH redraw, and it can look fine). Height-only drawer drags change rows, not columns, so they never produce this caret-in-prompt failure even with the same debounce.

Resize errors are silent (reportFailure: false). The RPC is concurrency: latest per session, which is fine; the hole is that panel width never forces a settled fit/flush the way drawer height does. No commit after v0.0.42 touches this path.

Related, not duplicates

Work	What it did	Why this still happens
Closed #4842 / bot: fixed by #4860	Drawer had a one-shot xterm fit. Ghostty added ResizeObserver and closed the drawer ticket	Same class of bug, different surface. Panel width never got the drawer’s resizeEpoch settle path.
Closed #4845, #3612	Pre-Ghostty “observe the container” PRs	Not merged. Superseded by Ghostty.
Closed #5320	Lockstep: apply Ghostty size only after PTY ACK	Not merged. Current code is the opposite: local first, PTY 150ms later.
Closed #445 / #620	Diff sidebar changed drawer width without a PTY resize	Historical drawer/xterm. Not the right-panel divider.
Open #11923	Drag-resize split panes; writes grid template to the DOM and relies on this same observer + debounce	Different gesture. Assumes the observer already keeps PTY in lockstep. Do not wait on it.

No other open issue claims the right-panel divider. Remote Ubuntu PTY vs macOS client is the same terminal.resize RPC the drawer uses.

Suggested fix

Keep this a small panel-width settle bugfix. Do not rebuild Ghostty resize or add a second observer.

1. Flush PTY size on panel drag end. When useResizableWidth / useResizeDrag finish() runs, the Ghostty surface should send the current cols/rows immediately (extract a flush from notifyResize). Keep the 150ms debounce during the drag so the prompt does not reprint every pixel.
2. Give the panel the same settle bump the drawer has. On width commit, increment resizeEpoch (or pass the settled panel width into TerminalViewport). height={0} must not be the only layout input. That covers the case where the mount box changed and fit() needs one more read after React commits the pixel width.
3. If narrowing still does not change mount.clientWidth, add min-w-0 on the h-full wrappers around TerminalViewport. Those are the only rungs in the panel stack without it. Do not start from a CSS rewrite.
4. Do not drop the mid-drag debounce, wait for feat(web): drag to resize split terminal panes #11923, or resurrect fix(terminal): keep PTY and Ghostty resize ordering in lockstep #5320’s lockstep for this.
5. Tests: shrink the mount, assert onResize is called with fewer cols; pointer-up flushes without waiting 150ms; widening still works. surface.test.ts currently stubs onResize as a no-op.
6. Visual close: right-panel terminal, long bash prompt, drag narrower than start, type. Caret sits after $. Repeat after Ctrl+L so both the live path and the workaround still work.

Do not treat “reopen the terminal” or auto-clear after every resize as the fix.

Workaround

Close and reopen the terminal, or clear / Ctrl+L after the drag once the shell has the new size. That reprints the prompt on the settled grid. No in-app control forces a panel-width refit on main.

Classification: bug · accepted · minor (web/desktop right-panel terminal; width-only drag leaves PTY/readline stale; Ctrl+L / reopen)
Labels: add accepted, via-triage; keep bug; remove needs-triage
Discord tags: ui