›_ Codex Issues
Codex Issues / #26494

Codex app composer loses caret and Chinese IME input after task completion

Open 💬 3 comments Opened Jun 5, 2026 by BigSmarti-hub
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

In the Codex desktop app, after a task finishes, the message composer can lose its visible caret. The composer still accepts English input, but the blinking caret is not visible, and Chinese input through the macOS input method cannot be entered.

Environment

  • Platform: macOS
  • Surface: Codex desktop app
  • Bundled Codex version: codex-cli 0.137.0-alpha.4
  • Date observed: 2026-06-05
  • Input method note: Rime/Squirrel is no longer installed or in use on this machine, so this is not specific to Rime.

What happened

  1. Use a normal Codex desktop app thread.
  2. Let Codex finish a task.
  3. Return to the composer at the bottom of the thread.
  4. The blinking text cursor/caret in the composer is gone.
  5. Switching to English input allows typing, but the caret is still invisible.
  6. Switching to Chinese input does not allow Chinese text entry.

Expected behavior

After a task finishes, the composer should keep or restore a normal editable focus state:

  • the caret should be visible,
  • English input should work,
  • Chinese IME composition should work.

Actual behavior

  • The caret disappears from the composer.
  • English typing can still insert text, but without a visible caret.
  • Chinese input cannot be entered.

Workarounds tried

Switching input methods does not fully recover the composer state. Restarting or refocusing the app may be required.

Impact

This interrupts follow-up prompts after a task completes, especially for users writing prompts in Chinese.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #25321
  • #26369

Powered by Codex Action

zengzheqing · 2 months ago

I am seeing the same class of bug, still reproducible on a newer Codex Desktop build.

Environment

  • App: Codex macOS App / Codex Desktop
  • Codex app version: 26.616.81150
  • CFBundleVersion: 4306
  • Bundle identifier: com.openai.codex
  • Electron/Chromium framework visible in process path: 149.0.7827.115
  • macOS: 26.5.1 build 25F80
  • Platform: Darwin 25.5.0 arm64
  • Bundled Codex CLI: codex-cli 0.142.0
  • System codex --version: codex-cli 0.142.1
  • Input method: macOS built-in Chinese Pinyin / Apple Simplified Chinese Pinyin

Observed behavior

During an ongoing Codex App session, especially after receiving an assistant response or after switching between several sessions/threads, the composer can enter a broken focus/IME state:

  • the text caret is not visible in the composer;
  • Chinese Pinyin IME composition cannot be entered or committed;
  • in some occurrences, direct English letters can still be inserted;
  • clipboard paste can still work, including pasted Chinese text;
  • clicking the composer repeatedly does not reliably restore the caret;
  • quitting and reopening Codex restores normal input until the issue recurs.

This matches the symptoms already described here and in related issues such as #26369, #25321, #27549, and #28872.

Reproduction pattern

The trigger is intermittent, but the pattern is:

  1. Open Codex Desktop on macOS.
  2. Use a normal local thread and type Chinese successfully with macOS built-in Chinese Pinyin.
  3. Let a Codex turn complete, or switch between multiple sessions/threads.
  4. Return to the composer and click it.
  5. Observe that the caret is gone or the composer does not fully focus.
  6. Try Chinese Pinyin input.
  7. Observe that the IME composition/candidate text cannot be committed into the composer.
  8. Try English letters or clipboard paste.
  9. In some cases, English letters or paste still work, which suggests normal key/paste events and IME composition events are diverging.
  10. Quit and reopen Codex.
  11. Observe that composer input works again temporarily.

Expected behavior

When the Codex window is active and the composer is clicked, the composer should always become the active editable target:

  • visible caret;
  • normal English input;
  • normal macOS Chinese Pinyin IME composition and commit;
  • no need to switch apps, refresh, or restart Codex.

Local log observations

I did not attach full logs because they may contain local/session data. A filtered macOS unified log around active composer/IME use showed repeated TextInputUI/IMK activity, for example:

2026-06-24 19:15:51.861 Codex[...] [com.apple.Foundation:general]
*** -[NSXPCDecoder validateAllowedClass:forKey:]: NSSecureCoding allowed classes list contains [NSObject class] ...
Protocol: IMKXPCServerProxy
SEL: handleEvent:characterIndex:edge:reply:
Classes: [IMKEvent, {}, {}, {}]

2026-06-24 19:15:52.095 Codex[...] activating connection: ... com.apple.TextInputUI.xpc.CursorUIViewService
2026-06-24 19:15:52.116 Codex[...] [com.apple.TextInputUI:CursorUI]
-[TUINSCursorUIController activate:]_block_invoke: Create CursorUIViewService: TUINSRemoteViewController

I do not know whether those messages are causal, but they match the affected layer: macOS TextInputUI / IMK / caret handling inside Codex's desktop shell.

Workarounds observed

  • Switching away to another macOS app and back may restore the composer.
  • Clicking another Codex UI surface and then returning to the composer may restore it.
  • Refreshing or restarting the app can restore it temporarily.
  • Typing Chinese elsewhere and pasting into Codex works when direct IME composition does not, but this is not a viable long-term workaround.

Developer-side hypothesis

This looks like a stale composer focus / first-responder / ProseMirror focus state issue in the Codex Desktop shell, possibly at the AppKit + Chromium/Electron + macOS IME composition boundary. The app seems able to receive some ordinary keyboard or paste events while failing to keep the composer as the correct IME composition target.

echonullx8 · 1 month ago

Additional data point: this is still reproducible on a newer Codex Desktop build, and in this case the usual focus workarounds do not recover the composer.

Environment

  • App: Codex macOS App / Codex Desktop
  • Codex app version: 26.623.70822
  • CFBundleVersion: 4559
  • Bundle identifier: com.openai.codex
  • macOS: 26.3.1 (a) build 25D771280a
  • Input method: Chinese IME on macOS (candidate/composition window affected)

Observed behavior

When a Codex thread/turn is running, the composer can get into a broken input state:

  • clicking the composer does not allow typing;
  • the Chinese IME candidate/composition window sometimes does not appear at all;
  • clicking outside the composer and then clicking back into it does not recover input;
  • switching to another Codex thread and then switching back does not recover input;
  • refreshing the Codex window with Cmd+R does not recover input;
  • the only reliable recovery observed so far is restarting Codex.

This makes the failure mode stronger than a normal missing-focus case. It looks like the app/renderer input or IME target state is stuck while the thread is active, rather than just the composer not being visually focused.

Expected behavior

Even while a Codex turn is running, the composer should remain usable as an editable target, including normal macOS Chinese IME composition/candidate behavior, without requiring an app restart.