Single Esc/Enter get duplicated in TUI, making undo unreliable

[MoYeRanqianzhi]

What issue are you seeing?

In one specific Linux server environment, Codex CLI appears to handle a single Esc or Enter keypress as if it were received twice.

A single Esc can behave like two escapes, and a single Enter can behave like a double submit. When trying to use undo / rollback, I also intermittently hit:

Error: thread/rollback failed in app-server TUI

This makes undo unreliable in practice, which is a blocker for my workflow because undo is one of the main reasons I rely on Codex CLI.

I do not see this on my other servers, so this looks environment-specific rather than a general usage issue.

What steps can reproduce the bug?

1. Use a Linux server desktop session.
2. In my case the environment is Ubuntu 24.04.1 with Xorg + i3 + Alacritty, accessed via RustDesk.
3. Launch codex-cli 0.117.0 in the terminal.
4. Press Esc once or Enter once inside the TUI.
5. Observe that the action can be interpreted as if the key was received twice.
6. Try to use undo / rollback and note that it can fail intermittently with thread/rollback failed in app-server TUI.

What is the expected behavior?

A single keypress should be handled exactly once, and undo / rollback should work reliably.

Additional information

I did some debugging on the affected server and found:

• In a plain terminal raw-byte capture, one Esc produced a single 0x1b, and one Enter produced a single 0x0d.
• After enabling a startup sequence that mimics Codex TUI keyboard negotiation, the same environment produced:
  • one Esc -> ESC [ 27 u followed by a separate raw ESC
  • one Enter -> 0d0d
• I also observed startup terminal replies such as focus / cursor / device responses during the same session.

Because of that, my current guess is that this is related to the TUI keyboard-enhancement / terminal-negotiation path in this environment, rather than a generic remote-control problem or a generic terminal problem.

The key point is that by the time Codex sees the input in this environment, a single Esc / Enter may already have become multiple input events, which then makes undo especially hard to use safely.

[github-actions]

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

• Each Cyrillic character appears duplicated while typing #16170
• VS Code terminal: CapsLock/Shift and key repeat broken in Codex prompt textbox #16189
• TUI startup/render path is rough under mosh #16302

Powered by Codex Action

[MoYeRanqianzhi]

Thanks. I reviewed the suggested issues.

This looks related to the same general terminal / keyboard-negotiation family, but I do not think this issue is a strict duplicate:

• Each Cyrillic character appears duplicated while typing #16170 is about duplicated Cyrillic character input on WSL / Windows.
• VS Code terminal: CapsLock/Shift and key repeat broken in Codex prompt textbox #16189 is about VS Code terminal keyboard-enhancement problems (Shift / CapsLock / key repeat).
• TUI startup/render path is rough under mosh #16302 is about rough startup / redraw behavior under mosh.

My issue is a different environment and a slightly different failure mode:

• Linux server desktop session
• Xorg + i3 + Alacritty
• accessed remotely via RustDesk
• single Esc / Enter can be interpreted as double input in Codex
• this also makes undo / rollback unreliable in practice, with intermittent thread/rollback failed in app-server TUI

I also captured terminal bytes on the affected machine:

• in a plain raw terminal capture, one Esc produced a single 0x1b, and one Enter produced a single 0x0d
• after enabling a startup sequence that mimics Codex TUI keyboard negotiation, one Esc produced both ESC [ 27 u and a separate raw ESC, and one Enter produced 0d0d

So my current understanding is:

• this is likely in the same broader keyboard-enhancement / terminal-negotiation area as VS Code terminal: CapsLock/Shift and key repeat broken in Codex prompt textbox #16189 and TUI startup/render path is rough under mosh #16302
• but the affected transport / environment and the observable user impact are different enough that this report is still useful on its own
• in particular, the undo / rollback breakage is the practical blocker here

Happy to close this if maintainers prefer to consolidate under a specific existing issue, but based on the current evidence I believe this is related-but-distinct rather than a clean duplicate.

[MoYeRanqianzhi]

Additional data point: Backspace is affected too, and the duplication appears to be intermittent / timing-sensitive rather than perfectly consistent.

I captured another terminal-byte log with the same Codex-like keyboard negotiation sequence enabled.

Observed behavior for a single Backspace press in the affected environment:

• sometimes it arrives as 7f7f in one read
• sometimes it arrives as two separate 7f reads very close together

So the symptom is not just "always two lines every time". It looks more like the same physical keypress can produce duplicate input events, but the exact delivery pattern varies:

• coalesced into one read (7f7f)
• or split across two nearby reads (7f, then 7f)

I also saw the same kind of behavior for other keys earlier:

• Esc: ESC [ 27 u followed by a separate raw ESC
• Enter: 0d0d

This makes me think the issue is timing-sensitive and likely related to mixed terminal keyboard-protocol / fallback event delivery in this environment, rather than a simple deterministic key-repeat problem.

This also strengthens the practical impact: it is not only text entry that is affected, but also destructive/editing keys like Backspace, which makes interactive use and undo/rollback behavior even less reliable.

[MoYeRanqianzhi]

Another important narrowing detail:

I can use Codex normally over a plain SSH terminal session.

The duplicated key behavior appears only when I use Codex inside the remote desktop session accessed through RustDesk.

So at this point the scope looks much narrower than "all remote sessions":

• plain SSH terminal: works normally
• RustDesk remote desktop session: affected

That seems consistent with the byte captures I posted earlier:

• the base terminal path itself is fine in a simple/raw case
• the problematic behavior shows up in the RustDesk-backed desktop environment once Codex-style keyboard negotiation is involved

So the issue is likely in the interaction between Codex TUI keyboard handling and the RustDesk/Xorg desktop path on this machine, rather than in SSH itself.

[MoYeRanqianzhi]

For maintainers, here is the clearest minimal reproduction path I can currently give.

Minimal reproducible environment

• Host OS: Ubuntu 24.04.1
• Display server: Xorg
• WM/session: i3
• Terminal: Alacritty
• Remote access method: RustDesk remote desktop into the graphical desktop session
• Codex version: codex-cli 0.117.0

Reproduction steps

1. Start the graphical Linux desktop session on the server.
2. Connect to that desktop remotely using RustDesk.
3. Open Alacritty inside the remote desktop session.
4. Run codex.
5. In the Codex TUI, press one of these keys exactly once:
   • Esc
   • Enter
   • Backspace
6. Observe that the key can be interpreted twice (intermittently).
7. Try to use undo / rollback and note that it can become unreliable, with intermittent thread/rollback failed in app-server TUI.

Important control comparison

On the same machine:

• plain SSH terminal session -> works normally
• RustDesk graphical desktop session -> affected

So the smallest known differentiator is not the host itself, but specifically the RustDesk-backed graphical desktop path.

What I observed while debugging

With a plain raw terminal byte capture in a normal terminal, single key presses looked normal.

With a Codex-like keyboard negotiation sequence enabled in the affected graphical remote session, I observed examples like:

• one Esc -> ESC [ 27 u plus a separate raw ESC
• one Enter -> 0d0d
• one Backspace -> either 7f7f in one read, or two nearby 7f reads

So the duplication seems intermittent and timing-sensitive, but reproducible in that environment class.