Codex Desktop pet overlay can leave the main composer without focus on macOS

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

On macOS, after opening the desktop pet overlay, Codex sometimes stops accepting input in the main composer.

The app is still frontmost. Clicking the composer does not always restore typing. Closing the pet immediately fixes it.

I originally noticed this with a custom pet at:

~/.codex/pets/doudou

The pet assets look valid: the spritesheet is 1536x1872, matching the expected 8 x 9 atlas with 192x208 cells. This does not look like an asset-format issue.

Environment

App: Codex Desktop
OS: macOS
Bundle: /Applications/Codex.app
Observed Chromium/Electron framework path: 149.0.7827.54
Custom pet: ~/.codex/pets/doudou

Steps

  1. Open Codex Desktop.
  2. Open the pet overlay.
  3. Switch away from Codex.
  4. Switch back to Codex.
  5. Click the composer and type.

Expected

The composer should accept input.

The pet overlay should still be visible and clickable.

Actual

Codex is frontmost, but the composer does not receive input.

Closing the pet overlay restores typing immediately.

Evidence

I captured the state with a local focus logger. During the broken state:

frontmost=Codex pid=59414
no focused window
no focused element
codex_window_count=2
codex_window name=Codex focused=false
codex_window name=Codex focused=false

CoreGraphics showed two Codex windows:

cg_window id=4314 pid=59414 owner=Codex layer=3 x=0 y=39 w=356 h=320
cg_window id=4182 pid=59414 owner=Codex layer=0 x=221 y=39 w=1579 h=1130

The layer=3 window appears to be the pet/avatar overlay. The layer=0 window is the main Codex window.

Unified log showed keyboard events still going to Codex:

destinations for Keyboard event: (<keyboardFocus; Codex.59414; token: viewbridge-key-window>)
delivery manager destinations for kCGSEventKeyDown event: <keyboardFocus; pid: 59414; token: viewbridge-key-window>

So the OS is sending keyboard events to Codex, but no focused element exists inside the app.

Local workaround tested

I patched the packaged app locally to stop the avatar overlay from taking keyboard focus.

The relevant packaged code is in:

/Applications/Codex.app/Contents/Resources/app.asar
.vite/build/main-*.js

The problematic path appears to be the avatar overlay keyboard interaction handler. In the packaged JS it does roughly this:

n.setFocusable(true);
n.show();
app.focus({ steal: true });
n.focus();
n.webContents.focus();

I tested a local patch that keeps pointer interaction working but prevents the overlay from becoming keyboard-focusable:

this.applyPointerInteractivityPolicy();
n.setFocusable(false);
return;

With that narrower patch, the pet remains visible and activity bubble clicks still work, while the main composer no longer gets stuck as easily.

Possible fix

The avatar overlay should probably not call setFocusable(true), app.focus({ steal: true }), window.focus(), or webContents.focus() unless an actual text input inside the overlay needs keyboard input.

Pointer interaction for pet messages/replies can remain enabled. Keyboard focus should stay with, or return to, the main Codex window/composer.

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

Powered by Codex Action

GrShin5 · 2 months ago

I can reproduce a very similar issue on macOS, but with an additional Japanese IME-specific symptom.

Environment

  • Codex App: 26.602.40724
  • macOS: Tahoe 26.2
  • Input sources tested:
  • Apple Japanese Romaji / Kotoeri: IME candidates appear, but committed text is not inserted.
  • ABC / Eisu: direct English input can still be inserted.
  • Codex Pet enabled
  • Reproduces with multiple built-in pet characters: yes

What happens
When I bring Codex to the foreground by clicking the Codex Pet overlay, the main chat composer enters an incomplete focus state.
The app appears to be foregrounded, but:

  • The composer does not show a blinking caret, even after clicking it.
  • English/ABC input can still be inserted.
  • Japanese IME composition candidates appear.
  • Pressing Enter to commit Japanese IME text does not insert the committed text into the composer.

Important trigger detail
This only happens when Codex is activated via the Pet overlay.
I do not see the same issue when bringing Codex to the foreground via:

  • Dock icon
  • Cmd+Tab
  • Mission Control
  • Clicking the Codex app window itself

Reproduction steps

  1. Open Codex App.
  2. Make another app active, such as a browser.
  3. Click the Codex Pet overlay to bring Codex App to the foreground.
  4. Click the Codex chat composer.
  5. Observe that the blinking caret does not appear.
  6. Type with English/ABC input: text can still be inserted.
  7. Switch to Japanese/Kana input.
  8. Type Japanese text.
  9. IME candidates/composition popup appears.
  10. Press Enter to commit the Japanese text.
  11. The committed Japanese text is not inserted into the composer.

Workarounds observed

  • Bringing Codex to the foreground via Dock, Cmd+Tab, Mission Control, or clicking the main app window avoids the issue.
  • If the bug occurs, clicking the Pet again after a short delay makes the caret appear and Japanese input works again.
  • Double-clicking the Pet does not fix it, but two slightly separated clicks do.

Hypothesis
This looks like a focus / first responder / text input client issue caused by activating Codex through the Pet overlay.
The Pet overlay seems to bring the Codex window to the foreground without fully restoring the WebView/composer text input focus state. ASCII key events can still reach the app, but Japanese IME composition cannot commit because the composer is not correctly registered as the active text input target.
This may be related to the overlay becoming keyboard-focusable or stealing/holding focus, as described in this issue.

liuyenhui · 2 months ago

This appears to be the same focus/caret issue tracked in #25321, with the desktop pet/avatar overlay as a more specific trigger.

I copied the pet-overlay reproduction details, local focus evidence, and workaround notes into #25321 here:
https://github.com/openai/codex/issues/25321#issuecomment-4638102993

Closing this as a duplicate so the focus/caret investigation can stay in one thread.