codex - 💡(How to fix) Fix Codex Desktop composer caret/input focus intermittently disappears on macOS until app focus is switched

What version of the Codex App are you using?

Codex Desktop 26.527.31326 (CFBundleVersion 3390)

Bundle identifier: com.openai.codex

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS 26.5 build 25F71
arm64

What issue are you seeing?

The Codex Desktop composer intermittently loses its visible text caret / input focus. When this happens, the prompt input area no longer shows the insertion caret and typing focus appears lost.

Switching focus away to another macOS application and then switching back to Codex restores the caret/input focus immediately.

This looks like a Codex Desktop window/text-input focus issue rather than a workspace, prompt, or project-specific issue. It has been observed in the current macOS desktop app, not in user project code.

What steps can reproduce the bug?

The exact trigger is intermittent, but the observed pattern is:

1. Use Codex Desktop on macOS normally in a thread.
2. After some UI interaction / elapsed time, the composer caret disappears or input focus becomes unreliable.
3. Switch to another macOS app.
4. Switch back to Codex.
5. The composer caret/input focus returns.

Actual behavior

The composer caret/input focus can disappear while Codex remains open and otherwise responsive. The recovery action is to switch away from Codex and back.

Expected behavior

The composer should keep or restore text input focus reliably when the Codex window is active, without requiring the user to switch to another app and back.

Diagnostics / additional information

Recent local macOS unified logs around the event show AppKit and TextInputUI activity inside the Codex process, including patterns like:

Codex[...] [com.apple.AppKit:Window] Window <ChromeNodeNSWindow: ...> ordered front from a non-active application and may order beneath the active application's windows.
Codex[...] [com.apple.AppKit:Window] order window front conditionally: ...
Codex[...] [com.apple.TextInputUI:CursorUI] ... Create CursorUIViewService: TUINSRemoteViewController

This seems consistent with a focus / first-responder / text-cursor bridge issue in the Codex Desktop UI shell, possibly related to AppKit + Chromium/WebView window handling on macOS.

Workaround

Switching to another macOS app and then back to Codex restores the caret/input focus temporarily. Fully quitting and reopening Codex may also reduce the frequency temporarily.