[Windows][TUI] PageUp/PageDown in the main transcript can snap scrollback to the bottom

Open 💬 0 comments Opened Jul 22, 2026 by snowyukitty

What version of Codex CLI is running?

codex-cli 0.144.6 on the primary reproduction machine.

The same user-visible behavior was independently reproduced on a second Windows PC. The currently published npm release is 0.145.0; I also inspected upstream main at 9fc715c, where the main-view key-routing gap described below is still present.

What subscription do you have?

ChatGPT subscription. This occurs entirely in local TUI/terminal input handling and is model- and subscription-independent.

Which model were you using?

Model-independent; it occurs while navigating an already-rendered transcript.

What platform is your computer?

Primary reproduction:

Windows 10.0.26200 (Windows 11 Professional) x64

Also independently reproduced on a second Windows PC.

What terminal emulator and version are you using (if applicable)?

  • Windows Terminal 1.24.11911.0
  • PowerShell 7.6.3
  • No terminal multiplexer
  • No custom Windows Terminal bindings for PageUp or PageDown
  • snapOnInput is not overridden, so Windows Terminal's documented default of true applies

Codex doctor report

The report below is intentionally minimized to remove local paths and project metadata. All checks completed successfully; the full redacted report is available if maintainers need it.

{
  "schemaVersion": 1,
  "overallStatus": "ok",
  "codexVersion": "0.144.6",
  "installation": {
    "status": "ok",
    "summary": "installation looks consistent",
    "method": "npm",
    "platform": "windows-x86_64"
  },
  "config": {
    "status": "ok",
    "summary": "config loaded"
  },
  "system": {
    "os": "Windows 10.0.26200 (Windows 11 Professional) [64-bit]"
  },
  "terminal": {
    "status": "ok",
    "terminal": "Windows Terminal",
    "WT_SESSION": "present"
  },
  "updates": {
    "latestVersion": "0.145.0"
  }
}

What issue are you seeing?

In Codex CLI's main inline transcript, unmodified PageUp / PageDown do not provide reliable page navigation. After scrolling several screens into terminal history with the mouse wheel or scrollbar, pressing a page key can immediately snap the viewport back to the input line at the bottom instead of moving by one viewport.

The failure was first noticed with PageDown on one PC. The same snap-to-bottom behavior was then observed with PageUp on a second PC. This is consistent with both keys following the same unhandled-input path rather than with a faulty key switch.

Control checks:

  • The physical PageUp and PageDown keys work normally in web browsers.
  • Ctrl+T opens Codex's transcript pager, where PageUp and PageDown perform page-wise navigation correctly.
  • Windows Terminal's native Ctrl+Shift+PageUp / Ctrl+Shift+PageDown scrollback actions work correctly.
  • The issue reproduces across two Windows PCs, so it is not specific to the original CHERRY keyboard or machine configuration.

What steps can reproduce the bug?

  1. Open Windows Terminal with a PowerShell profile and default snapOnInput behavior.
  2. Run codex and use the main inline view (do not open the Ctrl+T transcript overlay).
  3. Create or open a thread whose rendered transcript spans several terminal viewports.
  4. Use the mouse wheel or scrollbar to move several screens above the bottom.
  5. Press unmodified PageUp or PageDown.
  6. Observe that the viewport snaps to the bottom/input line instead of paging through the transcript.
  7. As a control, press Ctrl+T and repeat the page-key test; paging works inside that overlay.

What is the expected behavior?

PageUp and PageDown should move through the visible transcript by approximately one viewport, or Codex should route those keys into its transcript pager. They should not discard the user's current reading position by snapping to the bottom. End should remain the explicit jump-to-bottom action.

Additional information

Confirmed interaction causing the behavior

This appears to be a deterministic interaction between Codex's main-view input routing and Windows Terminal's documented default behavior:

  1. Codex defines PageUp / PageDown for the pager and list contexts, but not for the main inline transcript: keymap.rs lines 1094-1132.
  2. In the main view, otherwise-unmatched key presses are forwarded to ChatWidget: app/input.rs lines 238-252, then to the bottom pane/composer: bottom_pane/mod.rs lines 657-690. The composer has no PageUp / PageDown handling.
  3. Windows Terminal defaults snapOnInput to true. Its input path calls TrySnapOnInput() for a pressed non-modifier input key before returning the encoded input to the application: Terminal.cpp lines 620-633. TrySnapOnInput() resets a nonzero scroll offset to zero: Terminal.cpp lines 480-495.
  4. By contrast, Codex's Ctrl+T pager explicitly implements page-wise movement and keeps End as a separate jump-to-bottom action: pager_overlay.rs lines 253-284.

So Windows Terminal first snaps the native scrollback to the input line, and Codex then receives a key that its main transcript does not use. Disabling snapOnInput can avoid the snap as a local mitigation, but it still leaves the standard page keys without main-view paging behavior.

A possible Codex-side fix would be to intercept unmodified PageUp / PageDown when no modal, popup, or overlay is active, open the transcript pager, and apply the corresponding page action. At minimum, the main UI could make the Ctrl+T navigation path more discoverable on Windows.

Related but not duplicate:

  • #1064 — older, closed request where page keys did nothing in alternate-screen TUI mode
  • #7356 — pagination continuity inside the Ctrl+T overlay
  • #15380 — broader Windows Terminal scrollback/rendering inconsistencies

View original on GitHub ↗