Don't mess with the native TUI

I'd formulate it differently: Please spend more time on exploring if you can solve the issues you see with the current TUI (mostly: lines in the scroll buffer being overridden) without having to resort to using alt model. Losing native scrolling, search and text selection is too big of a price to pay. https://steipete.me/posts/2025/signature-flicker

Thanks for the feedback. We hear you, and we agree with a lot of what both of you are saying here.

I’d phrase a few things slightly differently, and I wanted to share some additional context on the work and trade-offs we’ve already been exploring. There’s a deeper write-up here if you’re interested:
https://github.com/openai/codex/blob/main/codex-rs/tui2/docs/tui_viewport_and_history.md

At a high level, there are three broad approaches to rendering in the terminal:

1. Render everything directly into the scrollback buffer and never update it

This is what Codex does today.

1. Render everything, but clear and re-render on resize

Ink takes this approach, and both Google and Anthropic are experimenting with variations here. We’ve explored this in the past, and it’s still something we may revisit as an optional path.

1. Own the viewport entirely with a full TUI

This is the direction of the current tui2 work, similar to OpenCode and others.

We’re intentionally experimenting in the open with multiple approaches before settling on a direction. We also have a very high bar for any change we’d roll out here. We’re terminal users ourselves. The explicit goal of the tui2 experiment is to get as close to native terminal behavior as possible within a TUI model.

Losing native scrolling, search and text selection is too big of a price to pay. https://steipete.me/posts/2025/signature-flicker

Scrolling fidelity is a P0 priority for the tui2 experiment. The “Future work and open questions” section of the doc above effectively represents a list of issues we don’t believe we can ship without addressing.

Search and text selection are also areas where a more TUI-aware approach can add value. For example:

• regex-based search
• selection that understands soft-wraps, even when we reflow output
• re-rendering wrap points for previously printed content when scrolling

One of the key benefits of fully owning the viewport is the ability to do smarter things with previously rendered cells as you scroll, including command output, diffs, and structured blocks.

This is still experimental, and we’re being very deliberate about the trade-offs.

One additional piece of context that may be useful is that terminal behavior varies quite a bit across environments. Different terminals make different trade-offs around scrolling, wrapping, resize behavior, mouse handling, and escape sequence support. In practice, there isn’t a single, fully consistent baseline that behaves identically everywhere, which is part of what makes changes in this space difficult to reason about and validate. Our goal is to be conservative and deliberate given that diversity of environments.

Thanks for all the feedback on the tui2 experiment. We want to close the loop openly on where this landed and why.

Over the past month or so we explored an alternative terminal UI architecture that fully owns its own viewport and transcript. The goal was to improve a few long-standing pain points, especially resize behavior, wrapping correctness, and copy fidelity for things like code blocks.

That work surfaced some real wins:

• Resize and rewrap behavior was significantly more stable and deterministic.
• Transcript-aware copy can produce much higher quality results, especially for code.
• Owning the viewport makes it easier to reason about history ordering and correctness.

At the same time, the experiment made one thing very clear: making a full-screen, transcript-owned TUI feel truly “native” across real-world environments is far more complex than it appears.

Terminals differ widely across operating systems, emulators, multiplexers like tmux, and input methods. Once you factor in scrolling, selection, copy shortcuts, mouse and trackpad behavior, keyboard layouts, and alt-screen quirks, the number of edge cases grows quickly. In practice, this meant that while tui2 worked well in some setups, it still felt like a regression in core terminal behaviors for others, especially around scrolling, selection, and copy.

Given that trade-off, we decided not to continue down the path of shipping tui2 as the default experience. We’ve removed the experimental code and feature flag rather than keep a parallel UI that we’re not confident we could make feel native everywhere in a reasonable timeframe.

Importantly, this is not a rollback of everything we learned. We are shifting focus back to the existing terminal-native UI and applying those learnings there. In particular, we are investing in a redraw-based approach that improves resize and redraw correctness while preserving native terminal scrolling, selection, and copy behavior. This keeps the compatibility surface much smaller while still addressing many of the issues that motivated the experiment in the first place.

We really appreciate the feedback, testing, and candid reactions from everyone who tried this. Experiments like this help us understand where the real constraints are, and they directly inform what we work on next. If you have specific terminal behaviors that feel broken or fragile today, please keep reporting them. That input is shaping the next iteration of the CLI experience.

The tui2 design doc link was invalidated by #9640 (looks like GH deleted the ability to see "deleted file at last existing revision", guessing it was too computationally expensive for them...) so here's a permalink to the tui2 design doc

Thanks for being so open about it! Very happy about this direction.

awesome

Happy about this too! It's a delight working with Codex CLI in whatever terminal.

Why would you remove TUI2 when some people love it / borderline need it in their setup? Why not leave it there while you work on improving TUI(1)?

EDIT: To be clear, I have no problem with leaving TUI2 behind and fixing TUI(1). I just don't understand forceably removing it on people who prefer it until TUI(1) is improved.

@darlingm, maintaining two implementations of the TUI and keeping them both in sync was a significant tax on the Codex team as we added new features and fixed bugs. It was never our intent to keep both of these implementations around for any length of time. This was a technical exploration, and we've learned what we needed from the experiment.