It's complicated.

Today, if you want to be able to drag to select text with the mouse to copy/paste, you have two not-so-great options:

• In iTerm, hold down alt while you drag. (Other terminals may have a different keybinding.)
• Use the [admittedly obscure] /toggle-mouse-mode command so that the TUI no longer processes mouse events itself. This will make text selection work "the normal way," but it also means that if you try to scroll the conversation area with your mouse, it won't work because the TUI is no longer receiving those scroll events. (You can use the keyboard shortcuts we provide to scroll, though.)

At this point, you are probably wondering: why does it work this way???

The TUI is built atop the Ratatui toolkit. By default, Ratatui encourages you to create full-screen TUIs. This means that if you want to have scrollback, you need to manage it yourself (as we do today).

Now that said, Ratatui does have an insert_before() API that would make it possible to "continuously append" to the TUI output like the TypeScript CLI does. The advantages of that scheme are:

• the user can use their terminal's native scrollback
• copy/paste "just works"

Though there are some downsides, which is that things like popping up menus is a bit weird:

#899

It is also more difficult to update content that is not "fully baked," such as a tool call with its own in-progress output or a spinner that appears above the input text box that needs to be continuously updated.

Nevertheless, it feels like, with enough effort, it should be possible to have the best of both worlds. That said, it seems that this issue needs to be solved to get there:

ratatui/ratatui#984

From the discussion, it sounds like it is not a trivial fix, so someone would need to invest some time there.

Counterpoint: do we want to cede scrollback to the terminal?

While the copy/paste thing is frustrating, I don't think having Codex manage its own scrollback is "obviously wrong." Personally, there have been many times where it was helpful that I could navigate through the conversation history while still having the text input available so that I could author my next user message while looking at what had transpired thus far.

In managing our own scrollback, there are a number of things we could do, such as:

• Support switching between multiple conversations/sessions.
• Making events in the history expandable so you could, e.g., see the full tool call output if you wanted to.

If copy/paste is really the primary motivator, then perhaps the real fix is to improve how we handle mouse events to support text selection in the way users expect?

/cc @joshka