Resize with OSC 133 prompt redraw accumulates duplicate prompt lines (regression in dde3d4d6b)

[stormzhang]

Resize with OSC 133 prompt redraw accumulates duplicate prompt lines (regression in dde3d4d)

Summary

After dde3d4d6b ("terminal: screen resize failures are now safe"), resizing the window with a shell that redraws its prompt on SIGWINCH (e.g. zsh + powerlevel10k) leaves stale prompt content behind on every resize. Duplicates accumulate with each zoom/drag cycle. Ghostty 1.3.1 does not have this problem.

Environment

• Ghostty: 7d748097a069768e12fa9bf63d598215a3e8f7a3 (1.3.2-dev), libghostty / GhosttyKit consumer on macOS; also reproduced with the stock Ghostty macOS app built at that commit. Still present on main as of 2026-08-05 (the clear is still after reflow in Screen.resize).
• macOS 26.4, zsh + powerlevel10k (two-line prompt; first line fills the full terminal width)
• Ghostty shell integration enabled (OSC 133 marks present)

Symptom

Open a fresh window, stay at the initial prompt, then resize the window (drag an edge, or double-click the titlebar to zoom/restore). Each resize adds another copy of (part of) the prompt. ghostty_surface_read_text confirms the duplicates exist in the terminal text model, so it is not a rendering artifact.

Notably, the condition is specific: a prompt whose first line is exactly full-width (p10k's right-aligned segments do this), drawn under OSC 133 marks, with a shell that redraws the prompt on SIGWINCH.

Bisect

• 89b103dd5 (terminal: more full featured resize) — good
• dde3d4d6b (terminal: screen resize failures are now safe) — first bad

I used a deterministic oracle for the bisect: a terminal-level test that replays a real zsh+p10k byte stream captured from a PTY (OSC 133 marks included) through Terminal + vtStream, performing 5 resize cycles of 80→100→80 cols with the shell's actual redraw bytes in between, then counting prompt occurrences in plainString. Result: 2 occurrences (baseline, same as 1.3.1) before dde3d4d6b, 7 after it.

Root cause

dde3d4d6b moved the redrawable-prompt clear (clearPromptForRedraw) in Screen.resize from before PageList.resize (reflow) to after it, so that a failed resize leaves the prompt untouched.

Clearing after reflow breaks the prompt lookup:

1. The p10k prompt's first line is exactly full-width. Reflow splits/moves such rows when columns change, and the resulting rows keep/duplicate their semantic prompt marks.
2. clearPromptForRedraw locates the prompt start via promptIterator(.left_up) from the cursor. After reflow mangled the marks (e.g. a split row tail marked .prompt, cursor landing on a .prompt_continuation row), the iterator finds a later start row.
3. The first prompt row is therefore never cleared. The shell then redraws the full prompt on SIGWINCH, and the stale row remains. Every resize adds another stale copy.

With the pre-dde3d4d6b ordering, reflow operates on already-blanked prompt rows, so nothing stale can survive — this is the behavior 1.3.1 shipped.

Proposed fix

Move the clear back before the fallible resize:

// Screen.resize, before `try self.pages.resize(...)`:
self.clearPromptForRedraw(opts.prompt_redraw);

and remove the post-resize call. The clear itself is infallible; if the resize then fails, the prompt cells are blank until the shell redraws on the next successful resize — the same trade-off 1.3.1 shipped for years.

One existing test needs a small adjustment: Screen: resize errors preserve state asserted the prompt survives a failed resize with prompt_redraw = .true; with the restored ordering that no longer holds, so the test now uses .false (it still verifies the fallible resize work itself is atomic).

Verification

• The replay oracle above: 7 duplicates → back to the 1.3.1 baseline after the fix. The same test fails on unfixed code, so it works as a regression test.
• On dde3d4d6b itself, moving only this call site restores the baseline — no other hunk of that commit is involved.
• Full zig build test suite at 7d748097a + fix: 3271 passed, 0 failed.
• End-to-end on macOS with a libghostty host app: 5 real-mouse titlebar zoom/restore cycles plus 5 window-edge drag cycles produce zero duplicates; cursor position and input remain correct.

I have the fix as a patch with the replay regression test and can open a PR if you'd like (I have not gone through the vouch process yet).

Possibly related

Discussion #9903 ("Dragging split divider causes repeated shell prompt insertion") describes a similar symptom, but it predates dde3d4d6b, so it may be a separate issue.

AI disclosure

This investigation (bisect, replay harness, root-cause analysis, fix, and this report) was carried out with AI assistance (Kimi Code). I reviewed the analysis, the fix, and this report, and verified the fix on my machine before submitting.

[nianchen8]

Adding a Linux data point on 1.4.0, in case it helps validate the fix.

Environment:

• Ghostty 1.4.0-arch1, GTK 4.24.1, OpenGL renderer
• GNOME Shell / mutter 51.1, Wayland, kernel 7.2.11
• zsh 5.9.2, Powerlevel10k d05a1b0, p10k-pure two-line prompt with a right-side clock on line 1
• eDP-1 2560x1600 at 4/3 fractional scaling (not required for the repro; see controls)

Repro on 1.4.0:

1. Fresh Ghostty window at the zsh prompt.
2. Press Ctrl+= three times, then Ctrl+- three times (font-size change; the window size does not change).
3. Or maximize/restore the window a few times.

Each grid resize leaves another copy of the prompt. After six font changes the window shows roughly 20 stale prompt banners plus an old clock. The stale content is present in a capture of the window itself, so it is not only a full-screen compositor artifact.

Controls:

• zsh -f (no p10k): clean, even after many resizes.
• p10k with POWERLEVEL9K_TERM_SHELL_INTEGRATION=true: still reproduces on 1.4.0.
• p10k in Ptyxis (GTK4/VTE) and GNOME Terminal (GTK3/VTE): stale prompts appear on window resize too, so the zsh/p10k side is not Ghostty-specific.
• Ghostty with Mesa llvmpipe and Ghostty under XWayland: still reproduces, ruling out NVIDIA/EGL and the Wayland-native 4/3 path.

I did not inspect the terminal text model, so I cannot confirm these are the same duplicated cells described in the report; visually the accumulation looks identical. On 1.4.0, #14706 is already included but #14707 is not. Is #14707 expected to cover this Linux case? I can build that branch and report before/after captures. I can also provide the images and logs.

AI disclosure: this investigation and draft were assisted by Claude Code; I reviewed the results and verified them on my machine.