Cursor movement (Left arrow) causes characters to visually disappear in JetBrains JediTerm since v0.129.0

Open 💬 1 comment Opened Aug 10, 2026 by JamesWangccc23

What version of Codex CLI is running?

0.129.0

What subscription do you have?

pro

Which model were you using?

_No response_

What platform is your computer?

Windows 10.0.19045.6466

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

JetBrains Rider 2024.3.10 built-in terminal (JediTerm)

Codex doctor report

What issue are you seeing?

Cursor movement (Left arrow) causes characters to visually disappear in JetBrains JediTerm since v0.129.0

What steps can reproduce the bug?

Environment

Codex CLI: 0.129.0+ (broken), 0.128.0 (works)
OS: Windows 10.0.19045.6466
Terminal: JetBrains Rider 2024.3.10 built-in terminal (JediTerm)
Shell: cmd.exe / powershell.exe (both affected)

Reproduce

Open Rider's built-in terminal
Run codex
Type test
Press Left arrow key
Character t visually disappears from screen

(buffer content is intact — pressing Enter still submits full test)

Regression range

0.128.0: works fine
0.129.0: broken

Workaround

Downgrade to 0.128.0.

Note

Other TUI tools (Claude Code, etc.) render correctly in the same terminal,
so this is specific to Codex's rendering strategy change in 0.129.0.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

1 Comment

jdcodes1 · 9 days ago

A concrete candidate for the 0.128→0.129 regression, from the source: that window introduced the vim composer mode machinery (#18595), and with it the terminal now emits a DECSCUSR cursor-style sequence on every single draw — draw() unconditionally calls set_cursor_style(cursor_style) whenever the cursor is visible (https://github.com/openai/codex/blob/1f41cc5d92/codex-rs/tui/src/custom_terminal.rs#L419-L435). Pressing Left triggers a redraw, so each keypress ships a fresh CSI Ps SP q.

DECSCUSR is one of the few common sequences with an intermediate byte (the space), and JediTerm's escape parser has historically been shaky exactly there — a parser that mis-consumes the intermediate can swallow or corrupt the cells written right after it, which matches your symptom precisely: visual-only loss on cursor movement, buffer intact (Enter submits the full text), while terminals with correct DECSCUSR handling are unaffected.

Verification without touching code: run codex under script (or PowerShell Start-Transcript-style byte capture) in JediTerm, press Left, and check whether \x1b[0 q-style sequences appear immediately before the corrupted redraw.

Repo-side fix that's worth doing regardless of JediTerm: cache the last-emitted cursor style and only write DECSCUSR when it changes (it's constant for non-vim users, so today's per-frame emission is pure redundant bytes). That would restore 0.128 behavior for everyone not actively toggling vim-mode cursor shapes.