Codex Desktop pet overlay can leave the main composer without focus on macOS
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
- Open Codex Desktop.
- Open the pet overlay.
- Switch away from Codex.
- Switch back to Codex.
- 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.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I can reproduce a very similar issue on macOS, but with an additional Japanese IME-specific symptom.
Environment
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:
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:
Reproduction steps
Workarounds observed
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.
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.