Codex CLI in browser xterm.js: cursor jumps during active turns and Chinese IME curly quotes are lost

What version of Codex CLI is running?

codex-cli 0.145.0

What subscription do you have?

ChatGPT subscription via ChatGPT sign-in (exact tier is not exposed by the CLI)

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

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

Omeety Terminal 1.0.0 in Microsoft Edge 150.0.4078.99 side panel; @xterm/xterm 6.0.0 + @xterm/addon-webgl 0.19.0; node-pty 1.1.0 / Windows ConPTY; TERM=xterm-256color; PowerShell 5.1 and cmd.exe; no multiplexer

Codex doctor report

codex doctor --json was run from a separate parent process because the affected embedded PTY is hosting the active Codex session.

Relevant report:
- overallStatus: warning
- codexVersion: 0.145.0
- runtime: standalone windows-x86_64
- OS: Windows 10.0.26200 (Windows 11 CoreCountrySpecific), zh-CN, 64-bit
- model: gpt-5.6-sol
- auth: ChatGPT
- config load: OK
- installation: OK
- state DB integrity: OK
- TERM=xterm-256color
- COLORTERM=truecolor
- console input code page: 936
- console output code page: 65001
- provider HTTP reachability: OK
- Responses WebSocket handshake: OK

What issue are you seeing?

Two related failures occur when Codex CLI runs inside a browser-hosted xterm.js terminal backed by Windows ConPTY.

1. Composer cursor visibly jumps/flickers during active turns

While a Codex turn is actively running (the UI shows Working, MCP startup, tool execution, or similar changing status rows), the text cursor does not stay at the composer position. It repeatedly flashes at transient coordinates, often at the ends of several status/output rows, then returns to the input line.

The problem is easiest to see while Codex is executing. When Codex is idle everything looks normal, so screenshots or tests captured only after completion miss the bug. Typing or deleting while the turn is active makes the movement more obvious.

This is not ordinary terminal cursor blinking. Disabling xterm cursor blink and setting Codex [tui] animations = false do not resolve it.

The same Codex binary/workflow does not show this cursor jumping in the local system terminal or the VS Code integrated terminal.

2. Microsoft Chinese IME cannot enter curly quotation marks in the composer

With Microsoft Pinyin in Chinese punctuation mode, the Codex composer cannot reliably receive the Chinese curly quote characters produced by the quote key:

• Shift+Quote should insert “ / ”
• Quote should insert ‘ / ’

Inside this browser-terminal Codex composer, the intended Unicode punctuation is not inserted correctly. Normal Chinese composition otherwise works.

There is no CLI error message. The second problem may be separate, but both failures occur at the Codex composer/cursor boundary in the same terminal host.

What steps can reproduce the bug?

Cursor reproduction

1. On Windows 11, open an Edge side-panel terminal implemented with xterm.js 6.0.0 + WebGL, connected to a real Windows ConPTY through node-pty.
2. Set TERM=xterm-256color and COLORTERM=truecolor.
3. Start codex (0.145.0).
4. Enter any prompt that keeps the agent working for at least 10 seconds.
5. While the UI shows Working, watch the composer cursor.
6. Type and backspace a few characters while the turn is still running.
7. Observe the cursor flashing/jumping between the real input position and temporary endpoints on changing status/output rows.
8. Let the turn finish: the cursor becomes stable again.
9. Run the same Codex binary in the local Windows terminal or VS Code terminal: the jumping is not observed.

Chinese quote reproduction

1. Keep focus in the Codex composer.
2. Switch Windows Microsoft Pinyin to Chinese mode with Chinese punctuation enabled.
3. Press Shift+Quote to enter a Chinese double quotation mark, then press Quote for a Chinese single quotation mark.
4. Observe that “”‘’ cannot be entered correctly in the live Codex composer.

An isolated xterm.js input probe that dispatches the IME direct-input path (keyCode=229, input.data=U+201C) delivers U+201C exactly once. The failure appears in the live Codex TUI/ConPTY interaction rather than in that isolated xterm input path.

What is the expected behavior?

During an active turn, the terminal should expose only the final composer cursor position. Intermediate cursor hide/show or temporary redraw coordinates should remain inside one synchronized update and should not become visible.

The Codex composer should also preserve standard Windows IME composition/direct-input events and accept the Unicode punctuation produced by Microsoft Pinyin, including “”‘’.

Additional information

Related issue: #32546.

That report describes Codex repeatedly toggling cursor visibility in WezTerm while the coordinates remain fixed. This report differs in two ways:

1. In the browser xterm.js/WebGL host, transient cursor coordinates are visibly rendered at multiple changing status-line endpoints, not only hidden/shown at one fixed coordinate.
2. The same environment also exposes loss of Chinese IME curly-quote input in the Codex composer.

Terminal stack:

• Omeety Terminal 1.0.0 (Edge side panel)
• Microsoft Edge 150.0.4078.99
• @xterm/xterm 6.0.0
• @xterm/addon-webgl 0.19.0
• node-pty 1.1.0
• Windows ConPTY
• TERM=xterm-256color
• COLORTERM=truecolor
• Microsoft Pinyin / zh-CN
• no tmux, screen, zellij, or WSL

The terminal host observed Codex using DEC synchronized-output mode (CSI ? 2026 h / CSI ? 2026 l) during redraws. The visible cursor jumps occur only during ongoing redraw activity, which suggests an intermediate cursor state is escaping between completed frames for some terminal implementations.

Microsoft Edge side-panel extension
  -> xterm.js 6.0.0 + WebGL renderer 0.19.0
  -> Chrome Native Messaging
  -> local Node.js native host
  -> node-pty 1.1.0
  -> Windows ConPTY
  -> PowerShell 5.1 or cmd.exe
  -> Codex CLI