Codex app output pane only shows about one screen and cannot scroll back

Open 💬 5 comments Opened Apr 26, 2026 by ruigulala
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Codex App Bug Report

Issue URL: https://github.com/openai/codex/issues/new?template=1-codex-app.yml

Title

Codex app output pane only shows about one screen and cannot scroll back through assistant output

What version of the Codex App are you using?

Unknown from About Codex dialog.

Observed CLI version in the same environment:

codex-cli 0.125.0

The command also printed:

WARNING: proceeding, even though we could not update PATH: Operation not permitted (os error 1)

What subscription do you have?

Unknown / not verified in this environment.

What platform is your computer?

Darwin 25.4.0 arm64 arm

Additional platform details:

ProductName: macOS
ProductVersion: 26.4.1
BuildVersion: 25E253
TERM_PROGRAM=iTerm.app
TERM=xterm-256color
COLORTERM=truecolor
SHELL=/bin/zsh

What issue are you seeing?

In the Codex app, assistant output appears limited to approximately one screen height. Long assistant responses are generated, but earlier lines become inaccessible: I cannot scroll back to the beginning of the response or prior output.

This does not appear to be a terminal scrollback problem. In another page of the same terminal, normal terminal scrollback works. For example, running:

seq 1 200

produces output that can be scrolled back normally.

The issue appears specific to the Codex app transcript/output pane.

Observed behavior:

  • Only roughly one screen of Codex output is visible.
  • Attempting to scroll up does not reveal earlier assistant output.
  • Long assistant responses appear to be inaccessible after they pass out of the visible viewport.
  • Normal terminal output outside Codex scrolls correctly.

What steps can reproduce the bug?

  1. Open Codex in iTerm on macOS.
  2. Ask Codex to generate a long response, for example many numbered lines intended for scrollback testing.
  3. Wait for the assistant response to finish.
  4. Attempt to scroll back to the top of the generated response.

Expected test prompt:

Generate 100 numbered lines so I can test whether the Codex output pane scrolls back.

Actual result: only about one screen of the assistant output is visible, and earlier lines cannot be scrolled back to.

Control test outside Codex:

seq 1 200

The control test scrolls normally in the terminal, which suggests the terminal emulator's scrollback buffer is working and the issue is in the Codex app output/transcript rendering.

What is the expected behavior?

Codex should preserve and expose scrollback for prior assistant output in the transcript pane. After a long assistant response, I should be able to scroll back to earlier lines in that response and previous transcript content.

Additional information

Likely areas to investigate:

  • The transcript/output container may have a fixed-height viewport without preserving prior rendered rows.
  • The scrollable container may have overflow: hidden or scroll may be attached to the wrong element.
  • A scroll-to-bottom behavior may be continuously re-triggering, preventing manual scrollback.
  • The app may be using a terminal/TUI alternate screen or equivalent rendering surface that only preserves the visible frame.

This was observed on April 25, 2026 in America/Los_Angeles timezone.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 4 months ago

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

  • #18528
  • #19584
  • #18658
  • #18978

Powered by Codex Action

ruigulala · 4 months ago

Found the solution in https://github.com/openai/codex/issues/2485.

For iTerm2, enable this profile setting:

Preferences/Settings -> Profiles -> Terminal -> Save lines to scrollback when an app status bar is present

After enabling that, Codex scrollback works as expected. iTerm2 appears to treat Codex's input bar as an app status bar, so without this setting it does not preserve the lines that scroll past the top of the terminal.

Closing this as an iTerm2 setting/workaround rather than a Codex bug.

etraut-openai contributor · 4 months ago

I'm going to reopen this because I'd like to look at whether we can make this work by default in iTerm2.

Andrewwilliamross · 1 month ago

Update after additional iTerm2 testing (2026-07-22): the recommended public artifact is now the focused native-scrollback branch: https://github.com/Andrewwilliamross/codex/tree/agent/fix-iterm2-native-scrollback. It contains only the isolated iTerm2 repair and avoids application-owned mouse capture. The broader owned-screen series remains available as an experimental prototype, but its virtual wheel scrolling is not yet comparable to Claude Code’s mature fullscreen scroller.

Thanks for reopening this to investigate making iTerm2 work by default. I reproduced it with iTerm2’s “Save lines to scrollback when an app status bar is present” setting disabled and traced the failure to Codex’s finalized-history insertion path.

Codex scrolls a partial terminal region to keep the composer in place. iTerm2 does not reliably promote rows scrolled out of that partial region into normal scrollback, so prior transcript rows disappear unless the profile workaround is enabled.

I implemented an isolated fix that selects native full-viewport scrollback insertion for iTerm2 while retaining the existing standard path for other terminals:

Validation:

  • four focused native-scrollback/iTerm2 regressions pass
  • full codex-tui suite: 3,259 passed, 4 skipped
  • package fixer and formatter pass
  • manual iTerm2 test passes with the profile workaround still disabled

If this direction aligns with the intended TUI behavior, I’m happy to open a focused PR if a maintainer would like to invite one.

Arpit-3000 · 17 days ago

Hi, I'd like to work on this issue. I can investigate the output pane scrolling behavior and work on a fix. Please assign it to me if it's available.