›_ Codex Issues
Codex Issues / #27036

Codex Desktop macOS composer enters partial focus state: cannot click/type, paste works, caret missing until submit

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

Summary

Codex Desktop on macOS can put the bottom composer/input bar into a broken partial focus state. Initially the composer does not accept normal click/type input. Paste can still work. After clicking again, typing may work, but the blinking caret is not visible. Submitting a message appears to reset/remount/refocus the composer, after which the caret and normal click focus return.

This originally looked like a Codex pet overlay issue, but tucking away/quitting the pet did not immediately restore the caret.

Environment

  • App: Codex Desktop
  • Codex version: 26.602.40724 (CFBundleVersion 3593)
  • OS: macOS 26.5.1 (25F80)
  • Architecture: arm64
  • Pet enabled: yes
  • Custom pets installed: yes
  • Also observed after pet was tucked away/quit

Observed Sequence

  1. Composer stopped accepting normal click/type input.
  2. Paste into the composer still worked.
  3. After clicking again, typed input worked, but there was no blinking caret.
  4. I tucked away/quit the Codex pet.
  5. The caret still did not return immediately.
  6. I submitted a pasted/typed message.
  7. Right after submission, clicking the composer worked again and the blinking caret returned.

Expected Behavior

Clicking the composer should focus it, show the blinking caret, and accept typing consistently.

Actual Behavior

The composer can enter a partial focus/render state where:

  • click/type initially fails
  • paste may still work
  • typed input may later work without a visible blinking caret
  • submitting a message appears to reset the composer focus/caret state

Diagnostics Captured During the Issue

While the issue was happening:

  • macOS reported Codex as the frontmost app.
  • Accessibility inspection reported no focused UI element for Codex: focused=missing.
  • The Codex pet overlay window was present earlier, but its bounds were bottom-left and did not cover the composer:
  • x=0, y=636, width=356, height=320
  • display bounds: 1470 x 956
  • Tucking away/quitting the pet removed the visible pet overlay, but did not immediately restore the missing caret.
  • A separate TypeWhisper utility window was visible in the window list at x=485, y=0, width=500, height=500, but it did not overlap the Codex composer area. It may explain unrelated top-search-bar click behavior, but does not explain the bottom composer caret issue.

This seems like a Codex Desktop composer focus/rendering bug, possibly triggered by overlay/window/focus interactions, but not directly fixed by closing the pet.

Related Issues

Possibly adjacent to existing Desktop UI/pet/compositor issues:

  • openai/codex#18341
  • openai/codex#20831
  • openai/codex#21088

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.

  • #26494
  • #26577
  • #26908

Powered by Codex Action

Siris1899 · 2 months ago

Additional live repro evidence:

This happened again with the pet active. The user could paste into the composer via a paste helper, but normal typing/Enter did not work and no caret was visible.

Important new observation: after pasting text and pressing Enter, text inside the Codex pet activity/status bubbles became selected/highlighted instead of the composer submitting. The user had to click the composer send arrow button to send.

Live diagnostics during that state:

  • Codex was frontmost.
  • Accessibility still reported focused=missing for Codex.
  • Pet overlay was open and visible.
  • Window list showed the Codex pet overlay as a separate Codex window at layer 3.
  • Pet overlay bounds at the time: x=0, y=522, width=356, height=320 on a 1470 x 956 display.
  • The pet overlay did not geometrically cover the composer, but selected text in the pet bubble indicates focus/selection was inside the overlay rather than the composer.

This makes the pet overlay/focus interaction much more likely than a simple geometry hit-test issue. It looks like the pet overlay can capture keyboard focus or selection while the main composer remains unable to show caret/handle Enter.

Siris1899 · 2 months ago

Closing as a duplicate of #25321. I added the live pet-overlay focus evidence from this report to #25321 here so the investigation stays consolidated.