Repeated ESC[0 q cursor reset in Codex v0.129.0 causes constant flicker under Emacs Eat

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

• #21666

Powered by Codex Action

Have you observed this behavior with previous versions? I'm trying to determine if this was a recent change or a long-standing issue.

I have not observed this behavior with previous versions.

I encountered a similar issue with codex-cli 0.129.0. The input cursor didn't flicker in the previous version, but it started flickering in the new version. The flickering cursor always disrupts my flow state. My environment is Windows + Windows Terminal, and this issue didn't occur in previous versions. It might be caused by the introduction of this feat: https://github.com/openai/codex/pull/18595

This is annoying. On KDE Konsole, I just get the letter q printed on top of the cursor when typing, and then any thinking steps flickers and adds qs in various spots.

<img width="463" height="306" alt="Image" src="https://github.com/user-attachments/assets/a4d865f9-8464-476d-9ce5-78c285ba6d06" />

Also similar to #21666

This comment was drafted and posted by Codex running locally on behalf of @leftos. It is not an OpenAI maintainer response.

I investigated this locally against current openai/codex main and a patched local build after seeing the same "cursor flashes at the end of the buffer while holding Space" symptom in a terminal host.

Findings:

• I did not find an open PR that addresses this exact path.
• #18595 appears to be the regression point for one part of the issue: Renderable::cursor_style and ChatComposer::cursor_style use SetCursorStyle::DefaultUserShape as the default, so the TUI emits ESC[0 q on normal frames. That matches this issue and #21666.
• Avoiding repeated ESC[0 q alone did not fix my repro. The visible end-of-buffer flicker was also caused by custom_terminal::Terminal::try_draw leaving the cursor visible while the frame diff is flushed. During self.flush(), the diff renderer moves the hardware cursor around to write changed cells. Current code then queues style, Show, and finally moves to the composer cursor position. Some hosts can paint the cursor in that interim state, which looks like the cursor flashing at the last rendered cell / end of buffer.

The local fix that eliminated the repro:

• Make cursor style optional (None means do not emit a cursor-style sequence).
• Only request SteadyBar for Vim insert mode.
• Track the active style override in Terminal and only emit style changes; reset to DefaultUserShape once when leaving a TUI-applied style, not every frame.
• In try_draw, queue cursor hide before flushing frame updates; after the flush, apply style, move to the final frame cursor position, then queue cursor show.
• Stop restore_common from unconditionally emitting SetCursorStyle::DefaultUserShape; Terminal::drop resets only if Codex previously applied a style override.

Validation:

• cargo test -p codex-tui cursor
• cargo clippy -p codex-tui --all-targets -- -D warnings
• Built codex-cli and tested the patched binary in Rustling Tulip; holding Space no longer shows the cursor flickering at the end of the buffer.

I have a local branch with the patch and tests, but the repository contribution guidance says external PRs are by invitation only, so I am posting the analysis and fix outline here instead of opening an unsolicited PR.