›_ Codex Issues
Codex Issues / #15083

Escape sequences ([110;1:3u) randomly inserted during prompt input

Open 💬 2 comments Opened Mar 18, 2026 by officiallygeorge

What version of Codex CLI is running?

codex-cli 0.115.0

What subscription do you have?

Pro

Which model were you using?

5.4 high fast

What platform is your computer?

macOS Darwin 25.3.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Ghostty + ZSH

What issue are you seeing?

When prompting the agent, escape sequences matching those described in this closed issue are randomly inserted at the cursor, e.g. [110;1:3u

What steps can reproduce the bug?

I believe the bug may be related to two codex agents in different split panes of the same window.

  1. Split Ghostty window into four full-width panes, one on top of the other.
  2. Panes 1 and 3 are codex agents working on separate projects/repositories
  3. Pane 2 and 4 are surfaces for user commands relating to the repos being worked on in 1 and 3 respectively.
  4. Prompt the agent in Pane 1
  5. Begin prompting the agent in Pane 3 – it appears that the reasoning in Pane 1 (possibly the conclusion of this, specifically) causes escape sequences to be inserted at the cursor.

What is the expected behavior?

For this to not happen.

Additional information

_No response_

View original on GitHub ↗

2 Comments

serima · 4 months ago

I’m seeing the same issue in a different environment.

Environment

  • Codex CLI: codex-cli 0.118.0
  • Platform: Darwin 25.4.0 arm64 arm (macOS 26.4)
  • Terminal: iTerm.app 3.6.9
  • Shell: zsh
  • TERM: xterm-256color

What I’m seeing

During normal prompt input, raw escape-sequence fragments such as [110;1:3u are occasionally inserted into the input buffer.

Notes

  • This is not limited to Ghostty in my case; I’m seeing it in iTerm2 as well.
  • In my case, this happens during ordinary interactive typing, not only after an SSH disconnect.
  • The inserted fragment I’ve observed is: [110;1:3u

If helpful, I can try to narrow down whether it correlates with pane switching, modifier keys, or multiple concurrent Codex sessions.

goodroot · 4 months ago

I am able to replicate this as well. If I have more than one instance of codex running in any circumstance, the second (original + n) will break in this way. I'm using Arch Linux and a tiling window compositor, so a very different setup than yours. And yet I am seeing the same strange behavior.

Looking at startup sequence via binary stream:

^[[>7u^[[?1004h^[[6n^[[?u^[[c^[]10;?^[\^[]11;?^[\

On startup, second instance sends:

  • ^[[>7u — enables Kitty keyboard protocol, flags=7 (key releases + alternate keys + event types).
  • ^[[?1004h — enables focus reporting. This is the [I / [O on window focus.
  • ^[[6n — cursor position request. Produces the [18;7R style responses.
  • ^[[?2026h — in-band resize protocol

When the second instance starts and connects to the existing session, it sets all these modes on the new terminal — but the input handling loop that would silently consume those responses isn't fully running (it looks like), so they fall through as literal text into the input widget.

---

Edit: Found root cause - https://github.com/openai/codex/issues/17622

It gets into this state because of this rewrite.