Initiating an Edit Triggers Start-to-End Chat/Session (Auto) Scroll-Down (Too Protracted)

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

• #12223
• #12945
• #13443

Powered by Codex Action

#12945 seems to highlights an eerily similar issue, though honestly since this whole tool might be vibe-coded itself (recursive improvement slop), it may still be pertinent to keep this specific triggering case on the watch for when someone does cater to this low-qos replayed scrolldown behavior.

Can you provide more details? I'm finding it difficult to understand the bug report. It mentions version 106, which is a CLI version. But it also mentions VS Code. Are you using the CLI in the VS Code terminal, or are you using the Codex VS Code extension?

When you say "initiating an edit", what do you mean?

Can you clarify the repro steps?

Can you provide more details? I'm finding it difficult to understand the bug report. It mentions version 106, which is a CLI version. But it also mentions VS Code. Are you using the CLI in the VS Code terminal, or are you using the Codex VS Code extension?

cli version 106 + vscode + tmux = cli version 106, in a vscode terminal, with tmux configured as a terminal multiplexer of the user environment
So yea, it's codex CLI...
Btw, this reproduces in other terminal emulators. It isn't exclusive to vscode.

When you say "initiating an edit", what do you mean?

(Assume without loss of generality that you're using the default key bindings)

Definition 1 (Initiating an Edit). Initiating an edit consists of:

1. esc esc: To enter edit mode
2. Scroll: To the prompt we want to edit
3. enter: To select the prompt, and revert the session back to that prompt and allow editing of that prompt.

Incidentally, upon the next enter, the session's old state will have wiped clean past the edited prompt, and the session will get to producing a response to the new edited prompt.
However, the initiation of the edit is defined as _the first enter_. That is, the one which wipes the session's state past the selected prompt, and brings the prompt-to-edit into the input box and allow to edit it.

Can you clarify the repro steps?

Definition 2 (Dense Session). A _dense session_ is a session with an abnormally large amount of cumulative previewed edits (i.e., not ones hiding behind a sub-agent's task, but edits that are done in the "foreground" of the response), and a large amount of prompt-response pairs. Let's set these imaginary thresholds at a few thousand lines, and a few hundred pairs.

Definition 3 (Replayed Scrolldown). Initiating an edit causes a replayed scrolldown. UI-wise, initiating an edit is ordered as follows:

1. Input box is populated with the prompt-to-edit, and the session's state is wiped clean past the prompt. _It is unclear the order of which these occurs_, hence the grouping into one step.
2. Replayed scrolldown: The CLI displays a scrolldown of some chunk of the session (perhaps all of it – again, unclear). It starts from the top of the chunk, to its bottom.
3. The input box becomes interactive. That is, up until this point, the input box is frozen.

This replayed scrolldown occurs invariably, without exception. It is awful to begin with and should be scrapped completely. This subpar ux decision probably went unnoticed since its significant shortcomings seem to have been surfaced so far only in the following context:

Pressing Issue: Replayed Scrolldowns in Dense Sessions Are Interminable. Initiating an edit in such sessions, sporadically (I'd say it's 50-50), takes an eternity.