Codex client output truncated when scrolling in Zellij

I get the same issue in multiple Mac based Terminals, inc the default. "Unlimited Scrollback" options can solve the issue if your software has it.

Hi, I am experiencing the same issue. Currently this prevents me from switching from claude code.

Same here, this behavior only started showing up very recently

Also seeing this on linux

have this as well, does not seem to be a problem with zellij. since claude code has no such issue

i've got some feedback from zellij's author that might be helpful

with the strong disclaimer that I have not tried to reproduce this myself and this is just an educated guess - this happens because the application is relying on the scrollbuffer in "Alternate Screen" (eg. with control code 1049), which the specification mentions should not exist (source: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html under "Alternate Screen Buffer").

I have tried in the past to be lenient with this behavior, because this is a common issue with some apps (can't blame them, not everyone spends time reading xterm specs), but allowing scrollbuffer in these cases causes a lot of other problems in apps that do follow the spec. Feel free to quote me on this.

I have the same issue.

guys. in the new version you can just use ctrl t to view the history. easy peasy way to circumvent this issue while it's not fixed

i've got some feedback from zellij's author that might be helpful > with the strong disclaimer that I have not tried to reproduce this myself and this is just an educated guess - this happens because the application is relying on the scrollbuffer in "Alternate Screen" (eg. with control code 1049), which the specification mentions should not exist (source: invisible-island.net/xterm/ctlseqs/ctlseqs.html under "Alternate Screen Buffer"). > I have tried in the past to be lenient with this behavior, because this is a common issue with some apps (can't blame them, not everyone spends time reading xterm specs), but allowing scrollbuffer in these cases causes a lot of other problems in apps that do follow the spec. Feel free to quote me on this.

Do you have a link to that message? I'm curious what mode he recommends to use instead.

The message was is zellij's discord

We'd be happy to have you there @wkrettek

you can find it here

https://zellij.dev/

you can ping me there, and then i just show you the message or you can ask the author yourself too

Same issue with tmux and zellij in Ubuntu 24.04 (omakub)

Same issue with Zellij on macOS.

same on zellij + ghostty + macOS

same on zellij + alaritty + macOS

Same on Zellij + Alacritty + Fedora (Wayland // Niri)

Same issue on: Kitty + Zellij (0.43.1) on Ubuntu 25.04

But I'm not entirely sure if I want it to be fixed!

Let me explain:

In Zellij, you can activate "Scroll / Edit Previous Message" Mode simple by pressing Esc twice.
Then you can scroll using muse wheel, touch pad or arrow keys (or as set in your zellij config).
Once done, just press q to quit.

This works well for me.

And in the normal mode, I can scroll to get CLI commands and messages that were present before I started codex.

Why would I want to change this?

We've fixed a number of bugs since this bug report was filed. Are any of you still seeing this problem with the latest version of codex CLI?

Scrolling still does not work for me in codex-cli version 0.58.0. Instead of displaying the codex history, previous messages from the shell are displayed

We've fixed a number of bugs since this bug report was filed. Are any of you still seeing this problem with the latest version of codex CLI?

the problem persists. the only way to actually view codex's history in zellij is with ctrl t

Thanks for confirming the problem still exists.

If someone from the community is interested in diagnosing this issue and contributing a targeted fix, we'd be interested in a PR. (Until recently, we were far behind in reviewing incoming PRs, but we have nearly caught up on our backlog.)

@etraut-openai see #8555 it disables alt mode in zellij (which is the root cause for scrolling issues) and also adds a --no-alt-screen flag

It seems that https://github.com/openai/codex/pull/8555 didn't fix it; see issue https://github.com/openai/codex/issues/9115

me and some other person from the zellij discord also noticed that the problem was not fixed despite the issue being closed

(I just forgot to let a comment here)

I have yet so see someone run codex on zellij with a working scrollback 😆

this question not solved , i use windows terminal -wsl-zellij-codex, i can't use zellij scroll mode to scroll page , i just use codex ctrl t to scroll , so it's inconvenient ,please fix it 😭

While this is waiting for a fix, I made a Python script that lets you pick a session to stream to your terminal: https://github.com/rochecompaan/nixdots/blob/main/modules/home/desktop/utils/codex-sessions/codex-sessions.py

I don’t know what Zellij is, but if you came here because you’re annoyed that the Codec CLI doesn’t stream to iTerm scrollback, the happy fix is to switch to the new Codex app. It has a much nicer UI for scrolling back and easily finding previous conversations. The only reason I can think to use the CLI version is if you want to run it in tmux/screen and SSH to connect to a running instance from another device.

Please fix this. Zellij is a requirement. I have Claude and Codex. Prefer Codex, but switching to Claude until fixed.

ctrl - t is overloaded so not a workaround

bumping up on this. None of the alternate screen fixes are working.

ok guys, thanks for jumping into this, it's now clear that this still has to be fixed

If you'd like to further "bump" the issue, just leave a 👍🏼 in the issue description at the top

no need for extra comment bumping, imo

hopefully someone from openAI will use the all-powerful 5.3-codex and fix it before we can say "zellj"

If someone from the community is interested in diagnosing the problem and suggesting a proposed fix (not in code, but in this thread), that would be welcome. The Codex team is a bit buried right now, and this issue frankly isn't near the top of our priority list at the moment.

FYI - I just submitted a PR that fixes this: #11221

@etraut-openai Apologies for doing things out of order... I proposed a PR to fix this, but now that I see your comment here, here's the more detailed proposal (I promise not to do it out of order in the future 😬):

I took a full pass through the inline TUI path and I think there are 3 bugs:

1. Make top-row history insertion robust

Current insertion logic has a fragile edge path when the viewport is at/near the top (especially full-height).

Proposed change:

• Use a dedicated insertion path for top-row/full-height cases
• Avoid the single-line DECSTBM + CRLF loop behavior in that case
• Normalize DECOM before margin/cursor operations
• Keep strict scroll-region validation (no zero/invalid bounds)
• Wrap insertion in save/restore cursor so we restore exact cursor state

2. Harden inline viewport/cursor heuristics (startup, resize, resume)

Cursor row-0 reports during startup/resize/resume can cause bad viewport realignment if accepted blindly.

Proposed change:

• Keep startup row-0 correction in inline tui::init (context-specific), not generic terminal construction
• Ignore suspicious resize jumps to row 0 when prior cursor state is sane
• Apply the same guard in suspend/resume realignment
• When viewport expands, clamp/reposition instead of scrolling transcript prefix region upward
• Sync last_known_cursor_pos in clear() and clear_scrollback() so later restores don’t drift

3. Fix streaming reflow accounting across width changes

There is a separate mid-stream resize issue where width changes can drop/duplicate lines due to commit accounting by rendered line count.

Proposed change:

• Track committed source-prefix length instead of committed rendered line count
• Recompute committed rendered boundary from that prefix after width changes
• Propagate width updates into active stream controllers before consuming new deltas

Likely related issues: #6427 #8555 #2558 #1478

Has this been merged yet? The no-alt-screen flag/config doesn't work to fix it in Zellij.

@seanmozeik Last I tested this PR (2 weeks) it did not seem to fix the issue.

keep the good work on the fix ❤️

I just tested codex --no-alt-screen and it solves the problem for me (I'm not using Zellij; I just want the output to go to Ghostty's scrollback instead of the codex built-in pager). ❤️

Unfortunately the --no-alt-screen flag is not working for me inside Zellij. I've also tried setting tui.alternate_screen = "never" in config.toml but to no avail.

Reference: https://github.com/openai/codex/blob/main/docs/tui-alternate-screen.md

Same issue Vs Code Win11

Using zellij 0.43.1. Is this a zellij issue or codex issue?

Using zellij 0.43.1. Is this a zellij issue or codex issue?

it is a codex issue, every other agentic tui works fine in zellij

there`s more info here: https://github.com/zellij-org/zellij/issues/4780 from zellij's author

If someone at openai can give me pro for a month I'll fix it xD
Now that codex is so good this is getting really annoying - I live in Zellij, haven't experience this issue with anything else so it must be something unique to codex.

im going to kill my self, please fix this bug guys

Tested on Linux (zellij 0.43.1). Even with --no-alt-screen, Zellij only retains the tail end of long responses in its scrollback history (e.g., only the last few lines of a 100-line output).

Problem

History insertion currently relies on scroll-region control sequences (DECSTBM + RI). Zellij does not consistently commit these sequences to its pane history the way it does with standard line-append output.

Proposed Fix

Modified tui and tui_app_server to implement a Zellij-specific path:

• Detection: Checks for ZELLIJ* environment variables.
• Behavior: For Zellij, it avoids DECSTBM/RI and instead appends history using standard CRLF and existing wrapped-line rendering.
• Legacy Support: Non-Zellij terminals continue using the original scroll-region logic to ensure no regressions.

Ready to submit as a PR if this approach looks good.

I’m still able to reproduce this on March 29, 2026 with codex-cli 0.117.0.

Environment:

• VS Code integrated terminal
• zellij 0.44.0
• Codex launched inside Zellij

Observed behavior:

• In normal shells / normal CLI programs inside Zellij, mouse wheel scrollback works as expected.
• The problem is specific to codex inside Zellij.
• Even after the tui.alternate_screen / --no-alt-screen fix from #8555, I still cannot use the mouse wheel to scroll back through Codex history the way I can with ordinary terminal output.
• Outside Zellij, normal terminal history scrolling behaves as expected.

This makes it look like the original alt-screen workaround either is not taking effect in this setup, or it does not fully restore the expected scrollback behavior once Codex TUI mouse/input handling is active.

So from a user perspective, the issue still reproduces in a current build: codex + zellij cannot reliably scroll back with the mouse wheel, while other programs in the same Zellij session can.

If useful, I can provide exact repro steps and config snippets.

Minimal repro on my side:

1. Open a VS Code integrated terminal
2. Start zellij
3. Run codex inside Zellij
4. Generate enough Codex history/output to require scrolling
5. Try using the mouse wheel to scroll back

Expected:

• I can scroll back through Codex history similarly to ordinary CLI output in the same Zellij session

Actual:

• mouse wheel scrollback does not work as expected for Codex
• other programs in the same Zellij session still scroll normally

Things I already tried:

• tui.alternate_screen = "never"
• --no-alt-screen
• restarting Codex
• restarting the shell / opening a fresh terminal
• starting a fresh Zellij session

Result:

• still reproducible

per @luccahuguet 's point about the imperfect ctrl t workaround. i didn't immediately realize that you have to "lock" zellij first with ctrl+g. then ctrl+t will use the codex cli "shortcut" that bring you into the transcript. also you have to remember to unlock zellij afterwards or you will go insane.

per @luccahuguet 's point about the imperfect ctrl t workaround. i didn't immediately realize that you have to "lock" zellij first with ctrl+g. then ctrl+t will use the codex cli "shortcut" that bring you into the transcript. also you have to remember to unlock zellij afterwards or you will go insane.

also I hate locking zellij, so in my project yazelix I remap some zellij keys to avoid conflicts with agents, and with helix: https://github.com/luccahuguet/yazelix (yazelix = yazi + zellij + helix)

also, Im itching to just fork codex and vendor the fork that works with zellij in yazelix (would install the codex fork by defaut when enabling codex in yazelix_packs.toml)

I tried the suggested Zellij workaround on April 1, 2026, and it does not actually solve the problem in my setup.

In my current Zellij keymap, locking/unlocking is on Alt+g (not Ctrl+g). After locking Zellij and then pressing Ctrl+t, Codex transcript/history does not open for me. Instead, I just end up back in regular Zellij mode / regular Zellij bindings.

So at least in my environment, this is not a reliable workaround for the actual issue.

The underlying problem I am reporting is still the same:

• ordinary CLI programs in the same Zellij session scroll normally
• codex does not behave like normal pane scrollback/history there
• Ctrl+t is not an equivalent replacement for normal Zellij scrollback behavior

So I do not think this issue should be considered addressed by the Ctrl+t workaround.

Following up on my analysis in: https://github.com/openai/codex/issues/2558#issuecomment-4103773428 , my previous fix only addressed chat history insertion only, while compatibility issues with other TUI elements remained, so I pursued a more comprehensive solution. My code is here for you guys to check: https://github.com/openai/codex/commit/cf9d10e51871eb4da8e4c1583253c8891c9556a0

Cause

The rendering issue in Zellij was caused by an interaction between Codex’s inline history insertion algorithm and Zellij’s pane scroll semantics.

In inline mode, Codex inserted transcript lines above the viewport using DECSTBM/RI-style region scrolling. On Zellij, this is unstable when the operation involves a region near row 0. The result was intermittent visual corruption: dropped lines, duplicated lines, stale rows, and occasional layout drift after / command redraws.

There was also a secondary ordering bug in redraw: when viewport geometry changed, clear() could run before the viewport switch, which could erase lines that should remain in transcript history.

Fix

The fix is compatibility-focused and minimal:

• Added a Zellij-specific history insertion mode selected by multiplexer detection (not tied to --no-alt-screen).
• In that mode, history insertion avoids the fragile top-row partial-region flow and avoids RI pre-scroll behavior that was causing drift.
• The insertion path now uses a stable sequence that preserves viewport anchoring while still pushing transcript output into scrollback.
• Reordered redraw behavior so viewport is set before clear on geometry changes, preventing accidental transcript erasure.

Non-Zellij terminals keep the existing ScrollRegions path.

@hjanuschka @etraut-openai could you please take a look at this? Appreciate your time.

@hjanuschka @etraut-openai could you please take a look at this? Appreciate your time.

I can't view your fork's commit. Just mentioning in case you meant it to be public.

Following up on my analysis in: #2558 (comment) , I’ve rebased the fix onto main and pushed a clean commit to my fork: Yana-Hangabina@46506bc Key changes: Added a Zellij-specific path that avoids DECSTBM/RI to fix scrollback issues. Maintained cursor restoration and history-row accounting. * Added regression tests for both Zellij and non-Zellij terminal modes. I’ve manually confirmed this fixes the truncated scrollback issue in Zellij when running with --no-alt-screen. @hjanuschka @etraut-openai could you please take a look at this? Appreciate your time.

<img width="888" height="476" alt="Image" src="https://github.com/user-attachments/assets/a34b0ddb-bfb2-4b84-9237-de181d6b10ea" />

@luccahuguet @rirze Sorry for the wrong link... Edited, qwq

Would it be possible for some of the Zellij users here try this PR and report back? It's not a silver bullet but it should at least get scrollback to work consistently.

Please test if you have the time and let me know.

https://github.com/openai/codex/pull/16578

A fix will be included in the next release (0.119.0). This is likely going to be a "peel the onion" exercise, so I anticipate that we'll need follow-on fixes. I'm going to close this issue. Please open new ones if you see additional problems related to Zellij.

Thank you!

@luccahuguet let us how if it works for you when you have a chance.

@luccahuguet let us how if it works for you when you have a chance.

Of course, I will as soon as I get home

A fix will be included in the next release. This is likely going to be a "peel the onion" exercise, so I anticipate that we'll need follow-on fixes. I'm going to close this issue. Please open new ones if you see additional problems related to Zellij.

@etraut-openai @fcoury-oai - I hope it's alright that I'm chiming in. With the help of a Codex user, we changed the Zellij behavior to match Codex's expectations: https://github.com/zellij-org/zellij/pull/4941 - this reportedly fixes the issue.

I plan to release a patch in the coming days, so may I suggest you revert the fix which (as I understand it) you're not pleased with and wait to see if this solves the problem for everyone?

If you experience other compatibility issues, I would love it if you could open an issue and I'd be happy to discuss and find a solution that works for everyone. If you do so, please tag me and mention this is about Codex compatibility, otherwise I might miss it. If you would rather do this privately, please see this as a personal invitation to email me.

I hope everyone has a good weekend otherwise.

For those who can't wait and still hitting problems
A quick fix you can do is run Codex inside Tmux inside Zellij

Incredible for Aram to step in here and try get this fixed! I had given up. Thanks so much to the OAI team too.

I built main off https://github.com/zellij-org/zellij/commit/d52e1aa2b8fbe7242c448fde677e26cf140f61f9 and it behaves totally as expected on the current codex release (0.118.0) -- i.e. before this new patch.

Note for testers that you have to make a NEW zellij session. Using the rebuilt binary on an old session will still be broken.

It also appears to work over ssh.

This is huge. Thanks everyone!

People of zellij. People of codex.

I've tested codex from https://github.com/openai/codex/commit/b5edeb98a0f3a7a0f43243f6ae06bc7de6cfacc0

Inside zellij v0.44.0...

and it just works

tested without any arguments, then closed it and brought it back with codex resume. It brought back the state from before, scrollback working super well.

Only nit is it will generate quite a bit of empty lines before the first prompt when you codex resume but it's harmless

Very satisfied with the result, as I use codex everyday for work and for my opensource project yazelix

Great that both OpenAI and @imsnif looked into this, I hope the zellij patch and codex patch work well together...

it would be great if someone tested both patches at once. and if it does not work, someone will have to revert, or reconcile..

But yeah, we went from no fix to two separate fixes quite quickly!

<img width="1488" height="840" alt="Image" src="https://github.com/user-attachments/assets/902b2728-c6e5-4348-acc3-d265e142decf" />

and here is it scrolling up a bit:

<img width="1488" height="840" alt="Image" src="https://github.com/user-attachments/assets/513fc104-c521-49ab-bec0-033944911a92" />

using --no-alt-screen on the other hand, seems a little glitchy as you can see (but I dont even know what's it for, and it's not the main path, so it's ok I guess)

<img width="1862" height="1015" alt="Image" src="https://github.com/user-attachments/assets/f381a468-14f9-49e1-92f1-6c77f505879f" />

Thanks everyone for testing!

Yesterday we released a patch with a mitigation for this issue in Zellij 0.44.1 (https://github.com/zellij-org/zellij/releases/tag/v0.44.1). IMO it would be best if Codex reverts their fix as it masks this mitigation and the Codex devs seem to think it's undesirable and hard to maintain (https://github.com/openai/codex/pull/16578#pullrequestreview-4052908488).

I believe that Codex implementing their own scrollback (eg. like vim, less, nvim, htop, OpenCode, etc.) rather than relying on undefined behavior will solve this and many similar issues. Happy to provide more details if anyone's interested.

My door, issue tracker and email address are always open to you. Peace.

Thanks @imsnif! Our current thinking is that we'll leave the fix in place within Codex for a little while (say, a month or two) and then remove it. That will give users a chance to update to the latest version of Zellij.

We are unlikely to implement our own scrollback. We investigated that approach late last year. Based on that prototyping effort and the feedback we received from users who tried it out, we concluded that there are too many downsides with that approach.