Codex desktop app composer loses focus after a turn completes

Open 💬 1 comment Opened Jun 11, 2026 by dingyh436-creator

What happened?

In the Codex desktop app, after an agent turn completes, the message composer often loses focus in a way that cannot be fixed by simply clicking the composer.

Clicking the composer does not show the text cursor/caret and typing does not appear to go into the input. A workaround is to click another app surface first, such as About Codex, then click back into the composer; after that, the cursor appears and input works again.

This happens frequently enough to interrupt normal use after completed turns.

Expected behavior

After a turn completes, clicking the message composer should focus it immediately and show the text cursor, so the next prompt can be typed without using another UI surface as a workaround.

Actual behavior

After a turn completes, clicking the composer does not show the cursor and the input remains unusable until another Codex UI surface is clicked first and focus returns to the composer.

Reproduction steps

  1. Open the Codex desktop app on macOS.
  2. Start any local thread/task.
  3. Wait for the agent turn to complete.
  4. Click the message composer.
  5. Observe that the cursor/caret does not appear and the composer is not usable.
  6. Click another app surface, for example About Codex.
  7. Click the composer again.
  8. Observe that the cursor appears and input works again.

Environment

  • App: Codex desktop app
  • Platform: macOS 26.5.1 (Build 25F80)
  • Codex app version: 26.608.12217 (CFBundleVersion 3722)
  • Bundled Codex CLI: 0.138.0-alpha.7
  • ChromiumBaseVersion: 149.0.7827.54

Log observations

I checked local Codex logs around a recent occurrence. I did not attach full logs because they may contain local/session data, but these snippets looked relevant.

Codex desktop log showed turn lifecycle messages for unknown conversations around task start/completion:

2026-06-11T06:16:49.835Z error [electron-message-handler] Received turn/started for unknown conversation conversationId=019eb553-831a-7a20-b9ce-466e6a599dc8
2026-06-11T06:16:49.860Z error [electron-message-handler] Received turn/started for unknown conversation conversationId=019eb553-831a-7a20-b9ce-466e6a599dc8
2026-06-11T06:16:55.257Z error [electron-message-handler] Received turn/completed for unknown conversation conversationId=019eb553-831a-7a20-b9ce-466e6a599dc8
2026-06-11T06:16:55.258Z error [electron-message-handler] Received turn/completed for unknown conversation conversationId=019eb553-831a-7a20-b9ce-466e6a599dc8
2026-06-11T06:16:59.108Z error [electron-message-handler] Received turn/started for unknown conversation conversationId=019eb553-a794-7ef3-9c6a-ff49fe13b1c7
2026-06-11T06:17:29.130Z error [electron-message-handler] Received turn/completed for unknown conversation conversationId=019eb553-a794-7ef3-9c6a-ff49fe13b1c7

macOS unified logs also showed TextInputUI cursor service activity around the time the composer/cursor behavior was being exercised:

2026-06-11 14:18:08.395 Codex com.apple.TextInputUI.xpc.CursorUIViewService activating connection
2026-06-11 14:18:08.429 Codex [com.apple.TextInputUI:CursorUI] Create CursorUIViewService: TUINSRemoteViewController
2026-06-11 14:18:11-14:18:29 Codex [com.apple.TextInputUI:CursorUI] scheduleUpdateCursorLocation repeated many times
2026-06-11 14:18:30.628 Codex com.apple.TextInputUI.xpc.CursorUIViewService activating connection
2026-06-11 14:18:30.653 Codex [com.apple.TextInputUI:CursorUI] Create CursorUIViewService: TUINSRemoteViewController

The unknown-conversation turn lifecycle errors may or may not be the root cause, but they coincide with the kind of state transition after which the composer focus/caret state becomes unreliable.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗