Codex CLI on macOS: Chinese IME / speech-to-text input not inserted into chat until pressing Enter (from second turn onwards)

Resolved 💬 2 comments Opened Dec 1, 2025 by YuancFeng Closed Dec 1, 2025

What version of Codex is running?

codex-cli 0.63.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.1-codex-max xhigh

What platform is your computer?

macOS on Apple Silicon (Cursor integrated terminal and Antigravity Codex terminal)

What issue are you seeing?

On macOS, when I use the system speech-to-text/dictation or the built-in Chinese Pinyin IME to input a mixed Chinese + English sentence into Codex CLI, starting from the second turn of a conversation the recognized text is not inserted into the Codex input line after dictation/IME composition finishes. The input line stays visually empty, but when I press Enter (or sometimes another key/newline) the buffered text suddenly appears and is usually sent as a full message immediately. This issue does not occur in the first turn of a fresh Codex CLI session but is reproducible from the second turn onwards. It happens in both Cursor’s integrated terminal and Antigravity’s integration. The same workflow on the same machine worked fine with older versions; this regression appeared only in recent releases.

What steps can reproduce the bug?

  1. On macOS, open a terminal that can run Codex CLI, such as the integrated terminal in Cursor or Antigravity.
  2. Run codex and sign in with a ChatGPT Pro account.
  3. First turn (works as expected): place the cursor in the Codex CLI input line and use macOS speech-to-text or the Chinese Pinyin IME to input a mixed Chinese/English sentence. When composition finishes, the text appears immediately in the input box and can be edited before pressing Enter to send.
  4. Second turn (broken): in the same Codex CLI session start a follow-up conversation. Use the same speech-to-text or IME workflow to input another sentence. After composition finishes, the input line remains empty; when pressing Enter (or sometimes any key/newline) the entire buffered text appears all at once and is sent. While the input is “invisible” normal editing is impossible; it feels like the keyboard is dead even though text is being buffered somewhere.

What is the expected behavior?

After speech-to-text or IME composition finishes, the recognized text should be inserted into the Codex input line immediately for every turn, not only the first. I should always be able to see and edit the text before sending it. Pressing Enter should only submit what is already visible, not reveal previously hidden input.

Additional information

This started only after the last one or two codex/codex-cli releases; older versions on the same machine with the same keyboard layouts, IME and IDEs did not show this problem. In diagnostics we observed that the locale inside the Codex process is normalized to LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 and other LC_* also zh_CN.UTF-8, with LC_ALL unset. System locale/region is AppleLocale=zh-Hans_DE and AppleLanguages=("zh-Hans-DE","de-DE"). Input sources include Chinese Pinyin (SCIM ITABC), German keyboard layout, CharacterViewer, etc. Terminals tested include Apple Terminal, Cursor and Antigravity terminals with TERM=xterm-256color; Secure Keyboard Entry is off. I previously had a custom codex() wrapper in ~/.zshrc that toggled bracketed-paste; it has been replaced by a minimal helper:

codex_ime() { LANG=zh_CN.UTF-8 LC_CTYPE=zh_CN.UTF-8 command codex "$@"; }
alias codex=codex_ime
alias fixtty='stty sane'

The bug reproduces even in this simplified setup, so it doesn’t seem caused by my original wrapper. The configuration file ~/.codex/config.toml has [tui] disable_paste_burst = true. Other options are related to approvals/sandbox/model selection and seem unrelated to IME. During diagnostics, stty -a </dev/tty after reproducing the issue showed the terminal in a raw-ish mode (-icanon -echo) which prevents macOS IME/dictation from doing normal line-buffered composition. Running stty sane (or my fixtty alias) after exiting Codex restores normal IME behavior. This suggests that after the first turn the Codex TUI may leave the TTY in a raw/no-echo state or not fully restore canonical input, so Chinese IME/dictation text is buffered but not rendered until a full line submit (Enter) occurs.

Hypothesis: this is a TUI/terminal-mode bug triggered by CJK IME/macOS dictation. The first turn correctly sets up and restores the terminal; in later turns the TUI input loop leaves the TTY in a raw/no-echo configuration, so IME/dictation composition does not redraw the line; the composed text only becomes visible when the buffer flushes on Enter. The symptoms are similar to issue #7203 (Codex CLI copy paste issue) where pasted text does not show up until the user presses a key; here the source is macOS Chinese IME/speech-to-text instead of a paste but the symptom (buffered text only appearing on keypress) is similar.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗