Codex Desktop composer caret/input focus intermittently disappears on macOS until app focus is switched

I am seeing the same symptom on my machine as well. Additional environment details from my local app/system:

• Codex Desktop: 26.527.31326 (CFBundleVersion 3390)
• Bundle identifier: com.openai.codex
• macOS: 26.5 build 25F71
• Architecture: arm64
• Hardware: MacBook Air Mac17,3, Apple M5, 24 GB memory

Observed behavior:

• While using Codex Desktop normally, the composer insertion caret sometimes disappears and the app stops accepting typing in the prompt input.
• Codex itself remains open/responsive, but the composer looks like it has lost input focus.
• Switching to another macOS application and then switching back to Codex restores the caret/input focus immediately.
• Other applications continue accepting keyboard input normally when this happens. I initially suspected the trackpad or input device, but the issue appears isolated to Codex Desktop.

I do not have a deterministic trigger yet, but the workaround is consistently to switch away from Codex and back.

same issue happened。Codex App： 26.527.60818（internal codex-cli： 0.136.0-alpha.2）
MacOS：13.7.8 (22H730)，Apple M2 Pro

I am seeing the same symptom on a newer Codex Desktop build, with additional evidence pointing to the pet/avatar overlay focus handoff.

Environment:

• Codex Desktop: 26.601.21317 (CFBundleVersion 3511)
• Bundled codex-cli: 0.136.0-alpha.2
• Chromium base: 149.0.7827.54
• macOS 26.5 build 25F71, arm64
• Pet/avatar overlay was enabled before the failure was investigated

Observed behavior:

• After an agent task completes, the composer sometimes cannot be selected or typed into.
• Codex remains visible/responsive, but the composer does not regain usable input focus.
• Switching to another macOS app and back restores input focus.
• Closing the desktop pet/avatar overlay removed an extra Codex window from the accessibility window list.

Sanitized accessibility/runtime evidence:

• In the stuck state, Codex was the frontmost app and had two Codex windows.
• The main Codex window reported AXMain=true.
• Both Codex windows reported AXFocused=false.
• AXFocusedUIElement was unavailable/empty for the Codex process.
• After closing the pet/avatar overlay, the Codex window count dropped from 2 to 1.

This looks like a "Codex is frontmost, but no Codex UI element is focused" state rather than a disabled composer/editor.

Additional local bundle inspection:

• The extra window appears to correspond to the pet/avatar overlay route /avatar-overlay.
• The command entry is openAvatarOverlay, with the menu title Wake Pet.
• The overlay open state key is electron-avatar-overlay-open.
• The overlay keyboard interaction path appears to focus the overlay while it is interactive, then make it non-focusable when keyboard interaction ends. I could not find an equivalent focus restore to the primary Codex window/composer on that exit path.

Hypothesis:

The pet/avatar overlay can steal focus and then become non-focusable without explicitly restoring focus to the main Codex window/editor. macOS can then leave Codex frontmost but with no focused UI element. Switching away and back forces the system/app to repair focus, which matches the workaround.

Expected behavior:

When the pet/avatar overlay exits keyboard interaction or closes, Codex should explicitly restore focus to the primary window/composer, or otherwise ensure the active main window has a valid focused UI element.

I am seeing the same issue as well. In my case it seemed to start after I enabled the desktop pet/avatar feature. I have since stopped/closed the pet, but I am still seeing the composer/input issue.

Environment:

• Codex Desktop: 26.601.21317 (CFBundleVersion 3511)
• Bundle identifier: com.openai.codex
• Bundled codex-cli: 0.136.0-alpha.2
• Chromium base: 149.0.7827.54
• macOS: 26.5 build 25F71, arm64
• Hardware: MacBook Pro Mac16,7, Apple M4 Pro, 48 GB memory

Observed behavior:

• When I paste/copy text into the composer input area, the input can become stale/unresponsive for a while.
• Actions that normally respond in milliseconds, such as clicking/focusing the composer or using Cmd+A / Backspace to clear the text, can take around 10 seconds, and sometimes closer to a minute before the command actually applies.
• Once I delete the pasted text from the input, the composer starts responding normally again.
• The problem started after enabling the pet/avatar overlay. The pet is now stopped/closed, but the issue still persists.

Expected behavior:

The composer input should remain responsive when pasting or editing text, and keyboard actions like Cmd+A / Backspace should apply immediately without needing to wait.

Adding the pet-overlay-specific reproduction from #26577 here, since this looks like the same focus/caret failure with a more deterministic trigger.

In #26577, the issue happens after opening the desktop pet overlay on macOS. Codex remains frontmost, but the composer does not receive input. Closing the pet immediately restores typing.

Local focus capture from 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 logs showed keyboard events still targeting Codex, but no focused UI element was present inside the app.

The packaged avatar overlay keyboard-interaction path appears to make the overlay focusable and explicitly focus it:

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

A local workaround that helped was to keep pointer interaction enabled for the pet/messages, but keep the avatar overlay non-focusable and avoid focusing its webContents. The better product fix may be to restore focus to the primary Codex window/composer when the pet overlay exits keyboard interaction or when Codex is activated via the pet overlay.

There is also a newer report on #26577 from another user with a Japanese IME-specific variant: activating Codex via the Pet overlay leaves the composer without a blinking caret; English input may still insert, but Japanese IME candidates cannot commit into the composer. That points to a first-responder/text-input-client focus handoff issue rather than just a visual caret problem.

Adding a related reproducible case here, since #26577 was closed and this issue appears to track the broader macOS composer caret/input focus problem.

I’m seeing a similar composer focus failure on macOS, but with a more specific trigger: activating Codex via the Codex Pet overlay.

Original comment with details:
https://github.com/openai/codex/issues/26577#issuecomment-4635083623

Environment

• Codex App: 26.602.40724
• macOS: Tahoe 26.2
• Codex Pet enabled
• Reproduces with multiple built-in pet characters: yes
• 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.

Trigger

This happens when Codex is brought to the foreground by clicking the Codex 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

What happens

After clicking the Pet overlay to bring Codex to the foreground, the composer appears to enter an incomplete focus state:

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

Workarounds observed

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

Why this may be relevant to this issue

This looks related to the broader macOS composer caret/input focus issue tracked here, but the Pet overlay provides a more specific and reproducible activation path.

My guess is that Codex is frontmost, and basic key events can still reach the app, but the WebView/composer is not fully restored as the active text input target. This seems to affect Japanese IME composition/commit more severely than direct ABC input.

Adding another live repro case from #27036 that seems to fit this canonical focus/caret issue, with a pet-overlay-specific focus clue.

Environment:

• Codex Desktop: 26.602.40724 (CFBundleVersion 3593)
• macOS: 26.5.1 build 25F80
• Architecture: arm64
• Pet enabled: yes, custom pet active

Observed sequence:

1. The bottom composer stopped accepting normal click/type input.
2. Paste into the composer still worked through a paste helper.
3. The composer had no blinking caret.
4. Esc did not recover focus.
5. Switching to another Codex thread and back did not recover focus.
6. Pressing Enter did not submit the composer.
7. Clicking the send arrow button still submitted the pasted text.

Important pet-specific clue:

When Enter was pressed while the composer was stuck, text inside the Codex pet activity/status bubbles became selected/highlighted instead of the composer submitting. This suggests keyboard focus/selection had landed inside the pet overlay, even though the overlay window did not geometrically cover the composer.

Live diagnostics during the broken state:

• Codex was frontmost.
• Accessibility inspection reported focused=missing for Codex.
• The pet overlay was open as a separate Codex window at layer 3.
• Pet overlay bounds were x=0, y=522, width=356, height=320 on a 1470 x 956 display.
• The main Codex window was layer 0.
• No other high-layer window overlapped the composer area.

This looks consistent with the hypothesis already discussed here: the pet/avatar overlay can capture or retain keyboard focus/selection, leaving the main composer in a partial focus state with no caret and no Enter handling.

Original duplicate report with the detailed timeline: #27036

Adding a current pet-overlay-specific update from a newer Codex Desktop build.

Environment

• Codex Desktop: 26.608.12217 (CFBundleVersion 3722)
• macOS: 26.5.1 build 25F80
• Architecture: arm64
• Pet/avatar overlay enabled

Current symptom

The issue is still reproducible in the current app for us: after waking/using the Pet overlay, the main composer can enter a state where Codex is frontmost but the composer cannot accept typing. Tucking/closing the pet overlay or forcing a normal app focus transition recovers typing.

This matches the earlier pet-overlay reports merged here from #26577 and #27036.

Local bundle evidence

The installed app bundle still contains two focus-stealing paths in app.asar under .vite/build/main-CIL4OHS5.js.

Root avatar overlay keyboard interaction path:

n.setFocusable(true);
n.show();
process.platform === "darwin" && app.focus({ steal: true });
n.focus();
n.webContents.focus();

Native composition surface focus handoff path:

e.window.show();
e.window.setFocusable(true);
e.window.setIgnoreMouseEvents(false);
onBeforeSurfaceFocus();
e.window.focus();
e.window.webContents.focus();

Both paths can make a pet/avatar overlay or composition surface become the keyboard-focused Electron window. That is consistent with the observed broken state where the Codex process is frontmost, but the main composer has no usable focused text input client.

Hot patch tested locally

I tested a local app.asar hot patch that keeps the pet overlay visible and pointer-interactive, but prevents the overlay/surfaces from taking keyboard focus:

// Root avatar overlay keyboard interaction:
this.applyPointerInteractivityPolicy();
n.setFocusable(false);
if (!isInteractive) return;
n.showInactive();
this.windowManager.sendMessageToWebContents(n.webContents, {
  type: "avatar-overlay-keyboard-interaction-ready",
});

// Native composition surface focus handoff:
e.window.showInactive();
e.window.setFocusable(false);
e.window.setIgnoreMouseEvents(false);
f?.(e.window);
e.keyboardInteractive = false;

After patching, the packaged bundle verifies that:

• the app.focus({ steal: true }) + window.focus() + webContents.focus() avatar overlay path is gone;
• overlay windows remain non-focusable;
• pointer interaction policy still runs.

Suggested product fix

The pet/avatar overlay should not become keyboard-focusable by default. Showing the overlay should use non-activating/inactive presentation, and pointer interactivity should stay separate from keyboard focus.

If there is an overlay text input that genuinely needs keyboard input, that mode should be narrow and should explicitly restore focus to the primary Codex window/composer when the interaction ends. On macOS, avoid the sequence “focus overlay, then later setFocusable(false)” because it can leave the app frontmost with no valid focused text input target.

I did not open an unsolicited PR because the public openai/codex checkout does not appear to include the Codex Desktop Electron shell source for this packaged app.asar path, and docs/contributing.md says external code PRs are by invitation only. This issue comment includes the concrete patch direction and the two packaged code paths that appear to need the upstream change.

Still reproduces on the current installed Codex Desktop build here:

• Codex Desktop: 26.611.61049 (CFBundleVersion 3996)
• macOS: 26.5.1 build 25F80
• Architecture: arm64
• Pet/avatar overlay enabled
• Custom pet active

Impact update: this effectively makes the pet feature difficult to use during normal composing. The pet/avatar itself is a favorite feature, but when the overlay/status bubbles steal or disrupt composer focus, the main Codex input can lose the blinking caret and stop accepting normal typing/Enter. Tucking/avoiding the pet is the only reliable workaround so far.

This matches the previous pet-overlay focus evidence in this thread: the overlay does not need to geometrically cover the composer to break input; the failure looks like a keyboard/focus handoff issue between the pet overlay and the main Codex composer.

Still reproducing here on a newer Codex Desktop build.

Environment:

• Codex Desktop: 26.611.62324
• Bundle ID: com.openai.codex
• macOS: 15.7.3 (24G419)
• Appearance: Dark
• Pet/avatar or floating overlay was visible when the issue occurred

Symptoms:

• Codex remains frontmost and otherwise responsive.
• The bottom composer does not show a visible caret.
• Clicking the composer does not reliably restore input focus.
• Esc, Cmd+R, switching focus, and quitting/reopening did not reliably recover the composer.
• Chinese IME input is affected: composition text cannot be committed into the composer, so I could only type raw pinyin-like text instead of Chinese characters.
• This blocks normal usage because prompt entry is the primary workflow.

This looks consistent with the pet/avatar overlay focus-handoff reports already collected in this thread: Codex is frontmost, but the main composer is not the active focused text input target. The overlay does not need to geometrically cover the composer to break typing/caret/IME behavior.

Practical workaround so far is to avoid using the pet/floating overlay to activate Codex and use Dock / Cmd+Tab / the main app window instead, but this is not a durable fix.

Adding another reproduction case with a Korean IME-specific symptom.

Environment:

• Codex Desktop: 26.611.62324 (CFBundleVersion 4028)
• Bundled codex-cli: 0.140.0-alpha.19
• macOS: 26.3.1 (a) build 25D771280a
• Architecture: arm64
• Input source: Korean via Gureum Keyboard (구름), 2-set Korean layout
• Pet/avatar overlay enabled

Trigger:

1. Make another app active.
2. Click the Codex Pet overlay once to bring Codex forward.
3. Try to click or type in the main composer.

Observed behavior:

• After the first Pet click, the composer appears to be in a partial focus state.
• The composer cannot be reliably selected, and the text caret/insertion cursor is not visible.
• With English input, typed characters can still appear, but the composer still does not show a normal caret/selection state.
• With Korean IME input through Gureum Keyboard (구름) 2-set, committed Korean text does not enter the composer.
• Clicking the Pet overlay one more time restores the composer focus/caret, and Korean input works again.

Expected behavior:

Clicking the Pet overlay to activate Codex should restore the main composer as a normal focused text input target, including visible caret/selection state and IME composition/commit support.

This looks consistent with the pet/avatar overlay focus-handoff reports already collected here: Codex becomes frontmost, but the main composer is not fully restored as the active text input client until the Pet is clicked again.

Just checking in: has anyone found a reliable fix or workaround for this? I opened the original issue quite some time ago, and the composer focus/caret problem still appears to persist in recent versions.

At this point, it seems pretty clear that the issue is related to Pets: when Pets is disabled, the problem does not occur; when Pets is enabled, it consistently reproduces.