[App][macOS] Chinese IME input intermittently stops working until ⌘R reload
Open 💬 2 comments Opened Jul 10, 2026 by yuanyuanlove
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
Summary
On the Codex desktop app for macOS, Chinese IME composition intermittently stops working in the message composer. The input field still appears focused, but Chinese text cannot be entered.
Reloading the Codex window with ⌘R immediately restores Chinese input.
Environment
- Product: Codex desktop app
- OS: macOS
- Input method: Chinese IME (exact provider not yet isolated)
- App version: Not recorded
- Language/locale: Not recorded
Steps to reproduce
- Open the Codex desktop app on macOS.
- Focus the message composer.
- Switch to a Chinese input method.
- Try to type Chinese text.
- Observe that Chinese text cannot be composed or entered.
- Press
⌘Rto reload the window. - Try again.
Expected behavior
Chinese IME composition and text input should continue working normally in the Codex composer without requiring a reload.
Actual behavior
Chinese input intermittently stops working. Reloading the window with ⌘R restores it.
Workaround
Press ⌘R to reload the Codex window.
The issue appears specific to the Codex composer; the exact trigger and whether it affects all Chinese IMEs are not yet known.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I can reproduce this issue on macOS, with additional symptoms and a live process sample captured while the failure was active.
Environment
com.apple.inputmethod.SCIM)Observed behavior
Live sample captured during the failure
The ChatGPT/Codex main process handled the key event through:
TSMProcessRawKeyEventWithOptionsAndCompletionHandler→
NSTextInputContext handleTSMEvent→
IMKInputSessionProcessEventRefWithCompletionHandler→
IMKInputSessionXPCInvocation_Modern invocationAwaitXPCReply→
HIRunLoopSemaphore waitAt the same time:
SCIM_Extensionwas idle in its XPC/AppKit run loop;pboardprocess appeared idle and healthy;This looks like a stale or broken IME XPC/native first-responder session in the app, rather than a keyboard hardware problem or a system-wide clipboard failure. Copy/paste failing alongside Chinese composition may be an important clue that the failure affects the native responder path more broadly.
I captured
samplereports for the main process, renderer, GPU process, SCIM extension, and pboard. I can provide sanitized excerpts if useful.