--no-alt-screen still does not preserve scrollback in xterm.js-based terminals (VS Code integrated terminal reproduces)`

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #12457
• #13443

Powered by Codex Action

I investigated this locally and pushed a proposed fix branch here:

https://github.com/jimbb/codex/tree/fix-inline-scrollback-safe-mode

Compare view:

https://github.com/openai/codex/compare/main...jimbb:fix-inline-scrollback-safe-mode?expand=1

I also tried to open a PR against openai/codex, but GitHub rejected CreatePullRequest for this account/repo combination, so I am linking the pushed branch directly.

Root cause here is that disabling alternate screen is not enough on its own. Outside the existing Zellij-specific branch, inline history insertion and viewport growth still use the DECSTBM / reverse-index path, which can drop or stale out global scrollback in xterm.js-style terminals on Windows.

This patch reuses the already-existing newline-based safe path, generalizes it to ScrollbackSafe, and applies it to the same inline-history failure mode beyond Zellij.

Related:

• #12457
• #14277
• #13443 (duplicate of #12457)
• #11192 (closed prior fix attempt on the same renderer path)

Given the current contributing policy says external PRs are by invitation only, would you prefer that I open this as an invited PR, or would you rather cherry-pick/take the branch directly?\n\nCompare: https://github.com/openai/codex/compare/main...jimbb:fix-inline-scrollback-safe-mode?expand=1\nCommit: 72151d628\n\nHappy to adjust the patch if this direction is close but not quite what you want.

hey, hit the same class of bug in Pane (my cross-platform terminal-first ai code assistant manager for running claude code / codex in parallel w/ git worktree isolation). xtermjs resets viewportY on every \x1b[2J, even inside a DEC 2026 sync block, so any full-redraw from codex yanks the viewport around mid-stream.

if youre building your own electron + xtermjs wrapper like OP: fix is to filter \x1b[2J at the PTY->terminal boundary when inside a \x1b[?2026h / \x1b[?2026l block. track sync state across chunks so you dont drop ED2 thats meant for regular clears. every other TUI (vim, htop, clear) is unaffected. https://github.com/Dcouple-Inc/Pane/pull/120

root issue is upstream in xtermjs tho. PR #5453 added DEC 2026 support for 6.0 but only implemented the "defer rendering" half, the "suppress viewport side-effects of ED inside BSU/ESU" half wasnt touched. just filed a dedicated xtermjs issue: xtermjs/xterm.js#5801

Adding another reproduction from Linux with Codex CLI 0.133.0.

In this environment, --no-alt-screen appears to be accepted by the CLI but does not produce a visible behavior change in the interactive TUI.

Version/environment:

codex-cli 0.133.0
Linux x86_64
TERM=linux in the shell
NO_COLOR=1
TMUX unset
Also tested under a pty with TERM=xterm-256color

I captured startup output for both forms with script and scanned for standard alternate-screen enter/leave sequences:

script -q -e -c 'TERM=xterm-256color timeout --signal=INT 1s codex' /tmp/codex-alt.typescript
script -q -e -c 'TERM=xterm-256color timeout --signal=INT 1s codex --no-alt-screen' /tmp/codex-noalt.typescript

perl -0ne 'print "enter1049=".(()=/\e\[\?1049h/g)." leave1049=".(()=/\e\[\?1049l/g)." enter47=".(()=/\e\[\?47h/g)." leave47=".(()=/\e\[\?47l/g)." bytes=".length($_)."\n"' /tmp/codex-alt.typescript
perl -0ne 'print "enter1049=".(()=/\e\[\?1049h/g)." leave1049=".(()=/\e\[\?1049l/g)." enter47=".(()=/\e\[\?47h/g)." leave47=".(()=/\e\[\?47l/g)." bytes=".length($_)."\n"' /tmp/codex-noalt.typescript

Observed:

default: enter1049=0 leave1049=0 enter47=0 leave47=0 bytes=7446
noalt:   enter1049=0 leave1049=0 enter47=0 leave47=0 bytes=7462

So in this setup the default path is already not emitting the usual alternate-buffer sequences, and --no-alt-screen has nothing visible to change. The TUI still clears/redraws the normal screen, so the practical outcome is the same as described in this issue: --no-alt-screen does not act as a true scrollback-preserving/append-only mode.

One related config detail: this build rejects boolean config values for tui.alternate_screen at TUI startup:

[tui]
alternate_screen = false

The accepted values appear to be string enums, e.g.:

[tui]
alternate_screen = "never"

Testing "always", "never", and "auto" in the same pty did not produce ?1049h/l either. This suggests the current option/documentation may be controlling only one part of the rendering path, while the full-screen repaint behavior that breaks native scrollback remains.