Pressing ↑ Makes Draft Prompt Disappear
What version of the VS Code extension are you using?
Codex 0.4.52
What subscription do you have?
PRO
Which IDE are you using?
VS Code
What platform is your computer?
MacOS
What issue are you seeing?
I just spent ~5 minutes working on a VERY PRECISE prompt and then pressed ↑ which caused ALL of my prompt to dissappear and get replaced with a previous prompt. When I pressed ↓, I could NOT recover the prompt I had been building.
INCREDIBLY FRUSTRATING!
What steps can reproduce the bug?
I was building my prompt, then decided I needed a new file as a scratch pad. I pressed CMD+N to create a new file, but the focus was in the codex chat, so it created a new chat. When I went back to the chat I had been working in, I pressed up for some reason, and it started cycling through previous chats, and wiped out my lengthy draft prompt.
What is the expected behavior?
First, I would have expected pressing up when there is content in the prompt to NOT do anything!
But having moved to a previous prompt, I would at least expect pressing down to eventually stop at my draft prompt, but no, it just cycles through past prompts, and it appears that my draft is gone.
I also HATE the UX that pressing down seems to cycle you through god-knows what. I would prefer pressing down to bring you to an empty prompt. I.e. up/down needs to be linear with bookends, not cyclic! Once I was pressing up/down, I completely lost where in my prompt history I was!
Additional information
_No response_
5 Comments
I'm not able to repro the problem you're reporting. Here's what I've tried:
When I do this, the partially-completed (but unsubmitted) prompt is still present.
Are you seeing something different?
No, I am not able to reproduce it now. Something like this def happened, but maybe it was a difficult-to-reproduce edge-case type trigger.
OK, I'm going to close the issue, but if you see it again — and especially if you're able to find a reproducible set of steps, please let us know.
I would like to request this issue be reopened. Although it has been difficult to provide a "100% stable" reproduction script, the core logic of the prompt input handling is flawed and poses a high risk of data loss for users.
The Pain Point:
I recently spent nearly two hours meticulously crafting a complex prompt. Due to a single accidental press of the Up Arrow (↑) key, the entire prompt vanished and was replaced by a previous short message. Pressing Down Arrow (↓) did not recover my draft.
Losing hours of "Prompt Engineering" work due to a single accidental keystroke is an incredibly frustrating experience and makes using Codex feel "unreliable."
Why this is a critical UX bug:
Destructive Navigation: In almost all modern IDEs and sophisticated chat interfaces, the "Up" key should only trigger history if the current input is empty, OR it should save the current unsubmitted text into a temporary buffer/stack.
Missing Draft Buffer: When moving to history, the current draft MUST be saved at the bottom of the stack so that pressing "Down" can bring it back. Currently, the draft seems to be permanently overwritten in certain states.
Cyclic History Issues: The cyclic nature of the history makes it impossible to know when you've reached the "end," further complicating the recovery of a lost draft.
Proposed Solution:
Do not trigger history on ↑ if the input field contains more than a certain amount of characters, or at least require a modifier key.
Implement a "Draft Buffer": Automatically save the unsubmitted text so that it is never lost when navigating history.
Linear History: Make the history navigation linear with clear boundaries so users don't get lost.
Please reconsider this issue. It is not just a "small bug," but a major user experience flaw that can lead to significant productivity loss
@junzhin, a "draft buffer" sounds like an interesting idea. Please open a new feature request if you'd like to see such a feature implemented.