[Bug] Codex chat input sometimes becomes unresponsive after opening Codex from the pet icon

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #26577
• #27036
• #27549
• #27357

Powered by Codex Action

Additional reproduction from another macOS environment.

When clicking the Codex pet / robot floating overlay to bring up the composer, the composer appears but cannot accept keyboard input.

Environment:

• OS: macOS
• Codex CLI: 0.125.0
• Codex app bundled Codex: 0.140.0-alpha.2

Observed behavior:

• The main Codex window composer works normally.
• After opening Codex from the pet / robot floating overlay, the composer is visible but text cannot be typed into it.
• Tucking away the pet restores normal input in the main Codex window.
• This looks like the floating overlay is not correctly receiving or returning keyboard focus.

Steps to reproduce:

1. Open Codex on macOS.
2. Wake Pet.
3. Click the Codex pet / robot floating overlay.
4. Try typing into the composer that appears.
5. The composer does not accept keyboard input.
6. Tuck Away Pet.
7. The main Codex window composer works normally again.

Expected behavior:
The composer opened from the pet floating overlay should receive keyboard focus and allow text input.

Actual behavior:
The composer appears, but keyboard input does not work.

Additional note:
Typing /feedback in the composer did not open a feedback dialog in this environment; it was sent as a normal message instead.

I can reproduce a very similar issue, and filed #28929 before noticing this thread. Adding a few more details that may help narrow the focus/IME behavior:

• Platform: macOS 26.5.1 (Build 25F80)
• Codex app bundled CLI: codex-cli 0.140.0-alpha.19
• Input method: WeType / WeChat Input Pinyin (com.tencent.inputmethod.wetype.pinyin)
• Trigger: switch away from Codex, then click the Codex Pet to return to Codex
• Actual behavior: the composer has no visible caret; Chinese IME text cannot be entered or committed; numbers and symbols can still be typed
• Workaround: switching to another app and then back to Codex restores input

This feels like the Codex window is activated, but the composer / macOS IME composition target is not fully restored when activation happens through the Pet. I am closing #28929 as a duplicate of this issue.

I can reproduce a similar issue on macOS.

Environment:

• Codex App: 26.616.32156
• CFBundleVersion: 4157
• macOS: 26.5.1, build 25F80
• Architecture: Apple Silicon / arm64

Observed behavior:

• After enabling Codex Pets, the composer/input box often cannot receive keyboard input.
• Mouse clicks also intermittently stop working or do not focus the input area.
• The issue happens frequently enough to block normal usage.
• Disabling the Pets feature makes the input and mouse behavior recover automatically.

Expected behavior:

• The pet overlay should not intercept or break mouse/keyboard focus for the Codex composer.

Possible cause:

• This looks like the pet overlay/window may be stealing focus or not passing pointer/keyboard events through correctly.

Workaround:

• Disable Pets.

Adding another data point with Korean IME on macOS. This looks closest to this issue rather than a general Korean-only IME issue, because the failure is most frequent when Codex is activated from the Pet entry point.

Environment:

• Codex App: 26.609.71450 (CFBundleVersion 3965)
• Platform: Darwin 25.5.0 arm64 arm
• App bundle: /Applications/Codex.app
• Input method: macOS Korean IME / 2-set Korean
• Feature involved: Codex Pet / Pet click entry into the Codex app

Observed behavior:

• After clicking the Pet to enter/open Codex, the composer sometimes appears visible but does not accept input.
• The broken state is intermittent, but frequent enough that Pet-based entry feels unreliable.
• The issue is especially obvious when trying to type Korean: Hangul composition may not appear or commit into the composer, so it feels as if input is disabled.
• This is not limited to a specific project prompt; it happens at the app/composer focus layer.

Likely trigger path:

1. Codex App is installed and the Pet feature is enabled.
2. Click the Pet / floating Pet entry point to bring Codex forward or enter the app.
3. Click the chat composer and try typing.
4. Intermittently, the composer does not accept typed input. Korean IME composition is the easiest way to notice the failure.

Expected behavior:

Opening or activating Codex from the Pet should leave the main composer as a normal focused text input target, including Korean IME composition and commit support.

Workarounds observed:

• Switching focus away from Codex and back can restore input.
• Switching input sources can sometimes help.
• Avoiding Pet-based activation and opening Codex through the normal app/window path appears more reliable.
• Restarting Codex also clears the stuck state temporarily.

I am not attaching logs/session IDs here because this is a public issue and local session content may contain private project/context data. The important added detail is the Pet activation path + Korean IME composition/commit symptom on 26.609.71450.

Adding another current reproduction with a default pet and a focus clue that may help narrow the overlay handoff path.

Environment:

• Codex Desktop: 26.616.81150 (CFBundleVersion 4306)
• Bundled codex-cli: 0.142.0
• macOS: 26.5.1 build 25F80
• Architecture: arm64
• Pet/avatar overlay enabled
• Pet type: default/built-in pet, not a custom pet

Observed sequence:

1. Had several queued coding tasks running in a thread, with the pet active.
2. After the queued tasks finished, navigated back to Codex and selected the original thread where those tasks had been running.
3. The main thread composer/text-entry area would not accept focus or keystrokes, even after clicking into it.
4. Pressing Tab highlighted the pet resize/maximize/drag affordance in orange. Pressing Tab repeatedly toggled focus/highlight on and off there, instead of moving focus into the main composer.
5. Clicking into a different thread, then returning to the original thread, restored the ability to click into the composer and send a new request.

Why this seems relevant:

• This reproduced with a default pet, so it does not appear to be caused by a malformed custom pet asset or the hatch-pet skill.
• The Tab behavior suggests keyboard focus was still in, or being routed through, the pet/avatar overlay controls after the background task completion/thread reactivation path.
• Switching threads appears to remount or reset the thread/composer focus state enough to clear the stuck overlay focus state.

Expected behavior:
After returning to a thread whose queued tasks have completed, the main composer should be clickable/focusable and should accept typing. Pet overlay controls should not retain keyboard focus in a way that prevents the thread composer from becoming the active text input target.

No logs or session transcript attached because this is a public issue and the session may contain private project context.

Adding another macOS reproduction that looks consistent with the composer focus issue described here.

Environment:

• Codex Desktop: 26.623.31443 (CFBundleVersion 4441)
• macOS: 26.5.1 (25F80)
• Architecture: x86_64
• App bundle: /Applications/Codex.app

Observed behavior:

• After Codex finishes running a task, the follow-up composer sometimes becomes unable to accept input.
• The placeholder is visible (Ask for follow-up changes), but the text caret is not visible and typing does not enter text.
• The UI looks like the thread is ready for follow-up input, so this feels like a stuck focus/composer state rather than the turn still running.
• Restarting Codex clears the problem. I have also observed that switching focus/thread or refreshing can sometimes recover similar focus issues, but in this case the user-visible workaround has been restarting the app.

Why this seems related:

• The failure happens after returning to a completed task/thread, not while the task is actively running.
• The composer is visible but does not become the active text input target.
• This matches the pattern where keyboard focus appears to be lost or retained by another app/overlay state after task completion.

Expected behavior:
After a task completes and the composer shows Ask for follow-up changes, clicking the composer should show the caret and allow typing without requiring an app restart.

Screenshot was captured locally, but I am not attaching the full image here because it may include private workspace context. The visible symptom is simply an empty follow-up composer with no caret.

Adding a newer reproduction that changes the likely scope of this issue: the composer can still become unresponsive after Pets are disabled/tucked away.

Environment

• macOS: 26.4 (25E246)
• Architecture: arm64
• Codex Desktop: reproduced on both:
• 26.707.61608 (CFBundleVersion 5200)
• 26.707.71524 (CFBundleVersion 5263)
• Bundled CLI on the latest reproduction: codex-cli 0.144.2
• Pets: disabled/tucked away before the latest reproduction

Reproduction pattern

1. Start a task in thread A.
2. Navigate away while the task is still running.
3. After the task completes, return to thread A.
4. The follow-up composer is visible, but clicking it does not place a caret and text cannot be entered.
5. Navigate to another thread and back to thread A, sometimes more than once.
6. The composer becomes interactive again and a new turn can be submitted.

Local log correlation

For the latest occurrence (local time, UTC+8):

• 10:36:00: the background turn completed and a desktop completion notification was emitted.
• 10:36:36: the primary Codex window was focused again. The renderer logged ResizeObserver loop completed with undelivered notifications.
• 10:37:01: navigation switched away from the affected thread.
• 10:38:28: navigation returned to the affected thread.
• 10:38:56: turn/start succeeded, confirming input had recovered after the thread navigation/reset.

During this latest reproduction, the internal avatarOverlay renderer remained Focused=false; it did not take focus. This suggests Pet focus stealing is not required to trigger the bug. The common pattern now looks more like a stale per-thread composer interaction state after a background turn completes. Navigating away and back appears to remount/resubscribe the thread view and clears the stuck state.

A previous occurrence on 26.707.61608 showed the same user-visible symptom and the same recovery after switching threads, although the avatar overlay did receive focus in that earlier occurrence.

Expected behavior

After returning to a thread whose background turn has completed, the follow-up composer should immediately accept pointer focus and keyboard/IME input without requiring thread navigation or an app restart.

I am not attaching raw logs or session IDs because the local sessions may contain private workspace context.

Adding a current reproduction with direct focus/renderer evidence.

Environment

Codex Desktop: 26.707.72221 (CFBundleVersion 5307)
Bundled codex-cli: 0.144.2
macOS: 26.5 (25F71)
Architecture: Apple Silicon / arm64
Keyboard layout: U.S.
Pet: custom glyph pet; avatar overlay enabled

Reproduction

Step 1 — Restart Codex; typing works normally.
Step 2 — Send one message while the pet overlay is active.
Step 3 — After the turn, the main composer remains visible but will not accept keyboard input, even after clicking it. Voice input still works.
Step 4 — Restarting Codex clears the problem temporarily, but it recurs.
Step 5 — Bringing the main Settings window forward restores focus. Tucking away the pet is the current workaround.

Focus correlation captured during the failure

The desktop log reported the main and overlay windows in opposite focus states at the same time:

Primary: rendererWindowAppearance=primary rendererWindowFocused=false
Avatar overlay: rendererWindowAppearance=avatarOverlay rendererWindowFocused=true

The persisted app state also showed electron-avatar-overlay-open=true. The GPU service was using roughly 40% CPU during the occurrence; a short process sample was dominated by IOSurface / QuartzCore / ColorSync composition work. The primary renderer also emitted repeated ResizeObserver loop completed with undelivered notifications errors while unfocused.

Opening codex://settings immediately changed the primary window to rendererWindowFocused=true.

I also inspected the current packaged desktop code. The avatar overlay’s keyboard-interaction path calls app.focus({steal: true}), followed by the overlay window’s focus() and webContents.focus(). That appears consistent with the overlay retaining keyboard focus instead of returning it to the main composer.

No raw logs or session IDs attached because they can contain private task context.

Additional workaround for the focus issue described above:

When the composer becomes unresponsive, clicking the pet once restores focus and makes the main composer accept keyboard input again.

This is currently the quickest recovery and avoids restarting Codex.

Adding a current macOS reproduction with a custom pet active.

Environment:

• Codex Desktop: 26.707.91948 (CFBundleVersion 5440)
• Bundle identifier: com.openai.codex
• macOS: 26.5.2 (build 25F84)
• Architecture: Apple Silicon / arm64
• Pet: custom pet enabled

Observed behavior:

• While the floating pet is active, the insertion caret intermittently disappears from the main prompt/composer window.
• The Codex window otherwise remains visible and responsive, but the composer no longer has a normal visible text-focus state.
• This appears consistent with the pet overlay retaining or disrupting focus rather than a problem with the prompt or project.

I have not yet established whether the same symptom occurs with a built-in pet, so I am reporting the confirmed custom-pet case only.

Expected behavior:

• The floating pet overlay should not take or disrupt keyboard/text focus in the main composer.
• Clicking the composer should always restore a visible caret and normal input focus.

I will add an update after comparing pet enabled versus tucked away, and custom versus built-in pet.