Windows TUI: collapsed edit results with long wrapped lines can corrupt transcript layout

[pashifika]

Description

A finalized edit result can grow from the bounded streaming preview into an arbitrarily tall collapsed card when the diff contains a small number of very long logical lines. On native Windows/ConPTY this shifts or interleaves the transcript/status rendering instead of settling to a compact … more lines result.

Reproduced on the latest release, omp/17.4.2, in Windows Terminal. The same reporter does not see the display corruption on macOS; there the result settles to the normal compact/more… presentation.

This is not specific to paths outside the project root. I reproduced it with both:

• a cwd-relative file inside the project;
• an absolute file under %TEMP% outside the project.

The in-project file alone is sufficient. The fixture is ASCII-only, so this does not require CJK/emoji width handling.

Steps to Reproduce

1. Start OMP directly in Windows Terminal at approximately 120 columns, with the default collapsed tool-output state (Ctrl+O not enabled) and no terminal multiplexer.

2. Create a file containing 12 lines of about 255 ASCII columns each:

   $tail = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789" * 4
   1..12 | ForEach-Object { "ROW_{0:D2}=$tail" -f $_ } | Set-Content -Encoding utf8 long-lines.txt

3. Send this prompt:

   Read long-lines.txt, then use one edit call to replace lines 3 through 10 with the same content plus `changed-` immediately after `=`. Do not use shell or scripts.
   

4. Watch the edit card while its arguments stream and when the tool result finalizes.

I also reproduced the same path in an interactive ConPTY-backed child OMP session by editing eight approximately 260-column lines in one hashline PUT 3.=10 operation. The bounded streaming preview settled into a finalized edit frame exceeding 60 physical rows at 120 columns, and transcript/status rows became interleaved. Four changed long lines are enough to make the finalized collapsed frame exceed a typical viewport.

Expected Behavior

Collapsed finalized edit output should be budgeted by rendered/physical rows, as the streaming edit preview already is. Once the budget is reached, it should show the existing … (N more lines) / expansion hint without corrupting or shifting the surrounding transcript.

Actual Behavior

The streaming preview is visually bounded, but finalization replaces it with a much taller wrapped diff. A few long logical lines become dozens of physical terminal rows. On Windows/ConPTY the surrounding transcript/status display shifts or interleaves instead of remaining stable.

Setting:

tui:
  scrollbackRebuild: true

does not bound the finalized card. It only changes the later scrollback-repair policy and therefore does not address the oversized final render.

Error Output

No process error or exception. This is TUI rendering corruption.

Platform

Windows (native)

• Windows 11 Pro, build 10.0.26200
• Windows Terminal 1.24.11911.0
• Direct terminal; no tmux/screen/Zellij

omp version

omp/17.4.2

Bun version

Not installed separately; reproduced with the official packaged Windows omp.exe release (bun --version is unavailable).

Provider

ChatGPT Plus/Pro (Codex). The failure is in tool-call rendering and does not appear provider-specific.

Area

TUI / Display

Additional context

The released renderer has different budgeting rules for the streaming and finalized phases:

• packages/coding-agent/src/edit/renderer.ts::formatStreamingDiff() calls sliceStreamingDiffTail() and explicitly budgets visual rows, counting wrapped rows at the frame's inner width.
• renderDiffSection() truncates collapsed finalized output with truncateDiffByHunk(..., PREVIEW_LIMITS.DIFF_COLLAPSED_LINES), which budgets logical diff lines.
• renderSingleFileResult() subsequently applies wrapEditRendererLine() to every retained logical line.

Therefore the finalized collapsed height is not bounded: fewer than DIFF_COLLAPSED_LINES logical lines can expand to an arbitrary number of physical rows after wrapping. The streaming phase already contains the visual-row-aware primitive and comments describing the stale-preview/native-scrollback failure this avoids.

The same renderer.ts path is unchanged between v17.4.2 and current main at the time of filing.

Related but not duplicate:

• Text summary mixing with command result when token poping too fast using grok4.5 #5341 tracks another mutable/tall streaming-content corruption path.
• TUI: wrap long tool-output lines in expanded mode instead of truncating #7081 requests wrapping for expanded grep output; edit output already wraps, and wrapping is the trigger here because the collapsed final budget counts logical rather than visual rows.
• RFC: consider app-owned virtual viewport for TUI rendering and scrollback #2040 discusses the broader native-scrollback tradeoff.

[roboomp]

Looking into this; I’ll report back with a renderer-level reproduction.

[pashifika]

Additional reporter observation about the lifecycle transition:

• While the edit/tool block is still streaming or in progress, the Windows TUI can look vertically cut or offset, as if the top/middle of the block has been clipped.
• Once the whole tool block finalizes/seals, OMP repaints it and the previously cut-looking content becomes visible correctly.
• The underlying tool result does not appear to be lost; this is transient live-render corruption/clipping that is repaired only by finalization.

This is consistent with the phase mismatch described in the issue: the live call is rendered through the bounded suffix window (formatStreamingDiff() / sliceStreamingDiffTail()), then the finalized component is replaced by renderDiffSection(). Intentional live-tail elision should show a stable frame plus an explicit ellipsis; it should not make the surrounding block/transcript appear cut or shifted, and finalization should not be required to restore the layout.

Observed on the same native Windows/ConPTY setup. macOS does not show the same transient cut/offset behavior.

[roboomp]

Reproduced on current main: a finalized collapsed edit with 12 approximately 255-column replacement lines renders 74 physical rows at 120 columns, while the collapsed 40-row diff budget plus card chrome should render 43 rows.

[roboomp]

Fixed in #9304. Finalized collapsed diffs are now clipped after gutter-aware wrapping, so the reproduced card settles at 43 physical rows instead of 74 at 120 columns.

[roboomp]

Thanks — that transient in-progress clipping is a different code path from what #9304 fixes, and it isn't the same unbounded-height defect.

The streaming/in-progress render already budgets physical rows: sliceStreamingDiffTail() (packages/coding-agent/src/edit/renderer.ts:429) counts wrapped rows via wrapTextWithAnsi(...).length at the frame's inner width, so a few long logical lines can't grow the live window unbounded. That's the exact primitive the finalized path was missing; #9304 makes finalization apply the same physical-row clip.

The "looks vertically cut/offset until finalization repaints it" behavior on native Windows/ConPTY is the native-scrollback commit-boundary tradeoff documented in formatStreamingDiff() (lines 463-495): the live block's volatile tail stays mutable, but rows that scroll past the terminal's scrollback commit boundary mid-stream are frozen as immutable history until the finalize repaint recommits the whole block. A byte-perfect live frame would require the alternate screen, which pulls the user out of their own scrollback — the broader tradeoff tracked in #2040. That's why it self-repairs on seal and why macOS (different scrollback commit semantics) doesn't show it.

So #9304 fully covers the finalized oversized-card corruption you originally filed; the transient live-clip is the ConPTY scrollback tradeoff rather than something this diff changes. Happy to keep it noted here for #2040's context.