Inline TUI history inserts use region scrolls that xterm.js deletes — permanent transcript gaps in VS Code terminal and other xterm.js hosts

This issue has persisted for many versions, severely impacting the user experience. It even led me to abandon the CLI and switch to a VS Code plugin, but the Claude Code CLI doesn't have this problem. I don't know how they manage to do it.

Additional data point from Linux / GNOME Terminal. This may be a related case rather than the exact same xterm.js root cause, but the user-visible failure mode is very similar.

Environment:

codex-cli: 0.139.0
OS: Ubuntu 22.04.5 LTS (Jammy)
Kernel: Linux 5.15.0-164-generic x86_64
Desktop/session: GNOME on X11
Terminal process detected: /usr/libexec/gnome-terminal-server
TERM: xterm-256color
COLORTERM: truecolor
Shell: /bin/bash
WSL_DISTRO_NAME: unset
WT_SESSION: unset
TMUX: unset
ZELLIJ: unset
VSCODE_IPC_HOOK_CLI: unset

Observed behavior:

• In normal multi-turn Codex CLI sessions, after sending a later prompt, parts of earlier transcript content visually disappear.
• The missing parts are typically chunks of previous assistant/user text rather than the whole session.
• This looks like a TUI rendering / transcript display problem, not necessarily actual model context loss.
• It has a large UX impact because earlier reasoning and instructions become visually unavailable during long sessions.

What I have not yet confirmed in this environment:

• Whether resizing the terminal reliably restores the missing text.
• Whether codex --no-alt-screen changes the behavior.
• A raw PTY capture showing the exact escape sequence frame where the text disappears.

Why I am adding this here:

This is confirmed on codex-cli 0.139.0, and the symptom matches the “transcript gaps / visually missing previous content” class of TUI issues described in this thread. If this GNOME Terminal / VTE case is considered distinct from the xterm.js region-scroll issue, it may be worth tracking separately or linking to the broader disappearing-history issue.

I am seeing a closely related scrollback/rendering symptom in Termius on iOS. I have not confirmed whether Termius uses xterm.js, and an important control test now suggests this may be a Termius-specific compatibility or resize/reflow case rather than the exact xterm.js root cause described in this issue.

Environment

• Codex CLI: codex-cli 0.144.6
• Installation: npm package @openai/codex
• Model: gpt-5.6-sol, reasoning effort low
• OS: Ubuntu 26.04 LTS
• Kernel/platform: Linux 7.0.0-28-generic x86_64 GNU/Linux (hostname omitted)
• Node.js: v24.13.1
• npm: 11.8.0
• Affected terminal: Termius 7.5.0 on iPhone/iOS
• Connection: SSH to an Ubuntu VM
• Terminal size when collected: 24 80
• TERM=xterm-256color
• COLORTERM unset
• No tmux, GNU screen, or Zellij
• Codex raw output mode enabled with /raw on
• Tested both tui.alternate_screen = "never" and codex --no-alt-screen

Observed behavior

After Codex completes a response longer than the mobile terminal viewport:

• The end of the response remains visible.
• The beginning cannot be reached using normal Termius scrollback.
• Scrolling upward reveals terminal content from before the response instead of the missing beginning.
• It appears that earlier response lines have been overwritten, hidden, or never committed to accessible terminal scrollback.
• Codex completes normally, returns to the prompt, and displays its completion time, so this does not appear to be model-output truncation.

Changing the terminal height affects the result:

• Hiding the iOS keyboard increases the terminal height and reveals more of the response.
• Showing the keyboard reduces the height and hides part of the response again.
• The missing beginning still cannot be recovered through normal scrollback.

A related problem occurs while editing a long pasted prompt: once the prompt exceeds the mobile viewport, its beginning becomes inaccessible.

Steps to reproduce

1. Connect from an iPhone using Termius 7.5.0 to an Ubuntu system over SSH.
2. Confirm TERM=xterm-256color.
3. Run Codex CLI 0.144.6 with raw output enabled and alternate-screen mode disabled.
4. Request a response longer than one mobile terminal viewport.
5. Allow the response to finish.
6. Scroll upward in Termius.
7. Open and close the iOS keyboard to change the reported terminal height.
8. Observe that only the later portion of the response remains accessible and older pre-response terminal content appears above it.
9. As a separate reproduction, paste a prompt long enough to exceed the viewport and attempt to access its beginning while editing.

Expected behavior

• The complete finalized response should remain available in normal terminal scrollback.
• Scrolling upward should reveal the beginning of the response.
• Terminal-height changes should reflow or redraw the viewport without losing or hiding finalized response lines.
• All parts of a long prompt should remain accessible while editing.

Troubleshooting performed

• Enabled /raw on.
• Tested tui.alternate_screen = "never".
• Tested codex --no-alt-screen.
• Confirmed TERM=xterm-256color.
• Confirmed no terminal multiplexer is active.
• Reinstalled Codex CLI.
• Removed an older duplicate launcher and confirmed that only one installation is active.
• Attempted to compare with Codex CLI 0.130.0, but the currently used model requires a newer CLI.
• Tried codex resume; it showed only a summary and did not restore the missing original response.

The transcript/collapsed-command-output feature appears separate and is not the source of this behavior.

Control tests

• The same Codex CLI works correctly when accessed through the VS Code integrated terminal over SSH to the same server. This still runs codex in the remote shell; it is not the Codex VS Code sidebar/extension UI.
• The failure reproduces specifically through Termius on iOS with the same remote Codex installation and server environment.
• Claude Code and Gemini CLI also preserve their output correctly through the affected Termius client, using the same SSH connection, Ubuntu system, terminal dimensions, and terminal settings.

Because the CLI works through VS Code Remote SSH but fails through Termius/iOS, the evidence points toward an interaction between Codex's TUI rendering and Termius's handling of scroll regions, terminal-height changes, repainting, or reflow. It may be related to this issue's disappearing-history class without sharing the exact xterm.js mechanism.

Screenshots are available and can be attached manually if helpful.

I can reproduce this on Codex CLI 0.146.0 in Cursor's integrated terminal with the launch chain Windows PowerShell -> WSL -> codex. The same WSL environment scrolls correctly when launched from Windows Terminal, which isolates the failure to the xterm.js-style host rather than WSL itself.

I built and tested a prototype against rust-v0.146.0: https://github.com/Little-Z7/codex-cursor-rich/blob/main/patches/codex-0.146.0-cursor-rich-scrollback.patch

The prototype:

• generalizes the existing newline-based insertion path into a scrollback-safe mode for VS Code/Cursor-like terminals;
• uses bottom-row CRLF/full-screen scrolling for finalized rich history insertion and inline viewport growth instead of DECSTBM/reverse-index operations;
• preserves ratatui colors and styles across pre-wrapped physical rows rather than switching to raw-output mode; and
• reuses the existing running_in_vscode_terminal() host probe, so PowerShell -> WSL still detects the VS Code/Cursor host when Linux-side TERM_PROGRAM metadata is absent.

The focused affected TUI suite passes 86/86, including escape-byte, bottom-alignment, replay, and styled-wrap regression tests. The same test step passed in GitHub Actions.

This overlaps with the prior work in #11192 and @jimbb's ScrollbackSafe prototype linked in #14277, and I would credit that prior art in the PR. My additional focus is preserving the current rich-history path and handling the Windows PowerShell -> WSL -> Cursor detection case.

Current main still contains the affected partial-scroll-region path. If this approach aligns with the intended fix, would a maintainer be willing to explicitly invite a PR? I can rebase it onto current main and submit a minimal source-and-tests-only change, without the standalone launcher/package files or release-version Cargo.lock churn.

Independent reproduction on a different xterm.js host, with a mechanism refinement for current versions and an arithmetic check that pins the loss to a specific call site.

Environment: Orca (Electron, @xterm/xterm 6.1.0-beta.287), Windows 11, codex-cli 0.146.0, spawned through node-pty with the bundled ConPTY (useConptyDll: true). Method: drive the real codex.exe through a PTY, capture every byte, and mirror the stream into a live @xterm/headless with the same options the renderer uses.

The history-insert path is already scrollback-safe on 0.146.0

This issue attributes the loss to the history-insert path emitting ESC[{k}S. That does not match what 0.146.0 actually writes. Per history line the capture shows:

ESC[1;25r        SetScrollRegion(1..area.top())  — top margin is row 1
ESC[25;1H        MoveTo(0, area.top() - 1)       — bottom margin of that region
\r\n             LF at the bottom margin
<line text>
ESC[r            ResetScrollRegion

That is a line feed, and xterm.js does push it to scrollback — the buffer grows and baseY advances. In a 4-turn capture there were 356 DECSTBM sequences and only 11 CSI n S, so the overwhelming majority of history arrives safely.

The remaining CSI n S comes from tui.rs, not from the insert path

Every surviving SU traces to scroll_region_up(0..area.top(), n), which ratatui expands to SetScrollRegion + crossterm ScrollUp + ResetScrollRegion. There are two call sites, both guarded by area.bottom() > screen_size.height:

• draw() → scroll_region_up(0..area.top(), area.bottom() - screen_size.height)
• update_inline_viewport_for_resize_reflow() → scroll_region_up(0..area.top(), scroll_by)

So Codex already contains the correct primitive in insert_history.rs; the overflow path just does not reuse it. That narrows the suggested fix considerably — the insert path needs no change, only those two call sites.

Arithmetic check

4-turn session, 160 history lines, no terminal resize performed by the harness:

| | |
| --- | --- |
| CSI n S events | 11 (10× CSI 2S, 1× CSI 1S) |
| Sum of scroll amounts | 21 |
| History lines lost | 21 |
| Blank rows left in scrollback | 19 |

The sum of scroll amounts equals the lines lost exactly, and all 11 SU events are immediately preceded by a row-1-anchored region (ESC[1;25r, ESC[1;23r) — precisely the case where those rows should have entered scrollback.

The blank rows matter for triage: scrollback keeps growing, it just fills with empty lines, which is why users report "earlier output is being erased line by line" rather than "output is missing".

The trigger is viewport height change, not terminal resize — this connects #30745

A control run with zero resizes still emitted one CSI 2S and lost 2 lines, fired by the composer collapsing at shutdown. Conversely, driving 1695 resizes (one-column pulse, rows 30↔28, and both combined; 7 MB of repaint traffic) lost 0 lines.

Loss therefore scales with conversation turns rather than output volume: 1 turn → 2 lines, 4 turns → 21 lines. A long session accumulates without bound.

This makes #30745 ("Codex TUI scrollback rows can disappear after inline viewport height changes") the same defect observed from the trigger side — that report has the right trigger but no mechanism, and this issue has the mechanism but attributes it to the wrong path.

ConPTY is not involved

Worth recording because #36474 was closed on the diagnosis that Windows discards lines scrolled out of a partial scroll region. That does not hold here.

A synthetic emitter replicating insert_history.rs byte-for-byte, which never emits SU, produced zero CSI S sequences after passing through system ConPTY, node-pty's bundled conpty.dll, and winpty. ConPTY does not synthesise SU — system ConPTY consumes the DECSTBM entirely and replays it as a bottom-of-screen \n, and the bundled DLL passes it through nearly verbatim. All three preserved 60/60 history lines.

So the SU originates in Codex, and the discard is standard xterm.js behaviour on every platform, not a Windows-specific one.

xterm.js behaviour, for reference

Scroll region ESC[1;25r, scrolled by 2, rows 1-25 pre-filled with markers, @xterm/headless 6.1.0-beta.287:

| Operation | Buffer length | Markers surviving |
| --- | --- | --- |
| \r\n at the bottom margin | 30 → 32 | 25/25 |
| ESC D (IND) at the bottom margin | 30 → 32 | 25/25 |
| CSI 2 S | 30 → 30 | 23/25 |
| CSI 2 T | 30 → 30 | 23/25 |
| CSI 2 M | 30 → 30 | 23/25 |

The buffer failing to grow is the reliable tell that rows were discarded rather than scrolled.

On the downstream mitigation

We prototyped the host-side workaround described in this thread and can confirm it works, with two caveats worth passing on to anyone else implementing it. It must fall through to the default handler both on the alternate screen and whenever the top margin is not row 1, since discarding is correct in those cases. And the scroll amount must be clamped to the region height — an unclamped CSI 999S faithfully scrolls 999 times and floods scrollback with blank rows.

Cursor position after the rewrite is identical to the default handler in every case we tested.

That said, a Codex-side fix in those two tui.rs call sites is the smaller and more correct change, since the correct technique already exists in the same crate.