[Windows][TUI] PageUp/PageDown in the main transcript can snap scrollback to the bottom
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
PageUporPageDown snapOnInputis not overridden, so Windows Terminal's documented default oftrueapplies
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
PageUpandPageDownkeys work normally in web browsers. Ctrl+Topens Codex's transcript pager, wherePageUpandPageDownperform page-wise navigation correctly.- Windows Terminal's native
Ctrl+Shift+PageUp/Ctrl+Shift+PageDownscrollback 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?
- Open Windows Terminal with a PowerShell profile and default
snapOnInputbehavior. - Run
codexand use the main inline view (do not open theCtrl+Ttranscript overlay). - Create or open a thread whose rendered transcript spans several terminal viewports.
- Use the mouse wheel or scrollbar to move several screens above the bottom.
- Press unmodified
PageUporPageDown. - Observe that the viewport snaps to the bottom/input line instead of paging through the transcript.
- As a control, press
Ctrl+Tand 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:
- Codex defines
PageUp/PageDownfor the pager and list contexts, but not for the main inline transcript:keymap.rslines 1094-1132. - In the main view, otherwise-unmatched key presses are forwarded to
ChatWidget:app/input.rslines 238-252, then to the bottom pane/composer:bottom_pane/mod.rslines 657-690. The composer has noPageUp/PageDownhandling. - Windows Terminal defaults
snapOnInputtotrue. Its input path callsTrySnapOnInput()for a pressed non-modifier input key before returning the encoded input to the application:Terminal.cpplines 620-633.TrySnapOnInput()resets a nonzero scroll offset to zero:Terminal.cpplines 480-495. - By contrast, Codex's
Ctrl+Tpager explicitly implements page-wise movement and keepsEndas a separate jump-to-bottom action:pager_overlay.rslines 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+Toverlay - #15380 — broader Windows Terminal scrollback/rendering inconsistencies