Codex App composer cannot be focused after opening from Codex Pet notification bubble on macOS

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

• #28872

Powered by Codex Action

I can reproduce a very similar issue on Codex macOS 26.623.101652.
When Codex is in the background, clicking the pet/avatar overlay brings Codex to the foreground, but then clicking the composer/input box can freeze or fail to focus.
Clicking the pet/avatar overlay a second time immediately restores the input box.
This happens with all pets I tested, so it does not appear to be caused by a specific custom pet asset.

I am seeing what looks like the same focus/activation bug on a newer Codex build, with a slightly broader symptom than only the composer.

Environment:

• Codex App: 26.623.101652
• CFBundleVersion: 4674
• ChromiumBaseVersion: 149.0.7827.197
• macOS: 26.5.1 build 25F80

Observed behavior:

• Click the desktop Codex Pet to bring Codex back to the foreground.
• The Codex main window appears, but clicks anywhere in the Codex UI often do nothing at first.
• Repeated clicking or switching away/back a few times eventually restores normal click handling.
• This feels like the main window is visible before it has cleanly become the active/key input target, rather than a normal renderer click-handler issue.

Recent unified log evidence from a reproduction around 2026-07-06 11:32:12-11:33:12 CST:

11:32:12.449 Codex[...] [com.apple.AppKit:Window] Window <ChromeNodeNSWindow: ...> windowNumber=17010 ordered front from a non-active application and may order beneath the active application's windows.
11:32:12.449 Codex[...] [com.apple.AppKit:Window] order window front conditionally: 17010 related: 0
11:32:12.450 Codex[...] [com.apple.AppKit:Window] Window <ChromeNodeNSWindow: ...> windowNumber=17010 ordered front from a non-active application and may order beneath the active application's windows.
11:32:18.557 Codex[...] [com.apple.AppKit:Window] Window <ChromeNodeNSPanel: ...> windowNumber=18468 ordered front from a non-active application and may order beneath the active application's windows.
11:32:18.557 Codex[...] [com.apple.AppKit:Window] order window front conditionally: 18468 related: 0
11:32:28.544 Codex[...] [com.apple.AppKit:Window] Window <ChromeNodeNSPanel: ...> windowNumber=18468 ordered front from a non-active application and may order beneath the active application's windows.
11:32:28.910 Codex[...] [com.apple.AppKit:Window] Window <ChromeNodeNSPanel: ...> windowNumber=18468 ordered front from a non-active application and may order beneath the active application's windows.
11:32:58.792 Codex[...] [com.apple.AppKit:Window] order window: 18468 op: -1 relative: 17010 related: 0
11:33:11.229 Codex[...] [com.apple.AppKit:Window] order window: 18468 op: -1 relative: 17010 related: 0
11:33:12.044 Codex[...] [com.apple.AppKit:Window] order window: 18468 op: -1 relative: 17010 related: 0

There are also TextInputUI / CursorUIViewService activations around the same period, which seems consistent with the app re-establishing input focus after the window ordering churn.

So this appears to affect the desktop pet / overlay path generally: after the pet brings the main window forward, the app/window/panel activation sequence can leave the visible main UI temporarily unable to receive mouse input until focus is cycled or enough clicks have occurred.

Still reproducible on Codex App 26.707.31428, build 5059, on macOS 26.5.1 (25F80), Apple Silicon arm64. Opening Codex from the desktop pet brings up the main window, but the composer does not accept keyboard input. Clicking the Codex icon in the macOS Dock restores input immediately. This matches the original report and confirms the bug persists in the newer app build.

I can confirm that this is still reproducible on the current macOS build available on this machine:

• Codex/ChatGPT App: 26.707.61608
• CFBundleVersion: 5200
• Electron: 42.1.0
• Chromium base: 150.0.7871.115
• Bundle ID: com.openai.codex
• Apple Silicon

The failure is specific to the user-initiated Pet notification path: clicking a Pet message opens the expected thread and makes the main window visible, but the composer is not a usable text input target until application focus is cycled or the Dock icon is clicked.

I performed a read-only inspection of the packaged app.asar from this signed build. The current main-process bundle still appears to handle the two paths differently:

• open-current-main-window with stealFocus === true is routed through the stronger primary-window activation path.
• The ordinary open-in-main-window path restores the window if minimized, then calls show() and focus(), but does not appear to activate the macOS application with app.focus({ steal: true }) or explicitly focus webContents.

That matches the observed behavior: the NSWindow is ordered/displayed, but the application/key-window/text-input handoff is incomplete.

Suggested fix direction:

1. Route the Pet notification open-in-main-window action through the same shared strong-activation helper used by the explicit open-current-main-window + stealFocus path, or make the shared helper perform the following for this user-initiated action on macOS:

• restore if minimized
• app.focus({ steal: true })
• window.show()
• window.focus()
• window.webContents.focus()

1. Keep strong focus stealing limited to explicit user actions such as clicking the Pet/notification, not background notification delivery.
2. Add regression coverage:

• Main-process unit test: on Darwin, open-in-main-window from the avatar notification invokes application activation and focuses the target window/WebContents.
• macOS E2E test: background Codex, click a Pet notification for a thread, assert that the app/window/WebContents become focused and that text can immediately be entered into the composer.

I checked the current public openai/codex main branch as well. The Electron/macOS desktop source that owns these IPC handlers does not appear to be present there, so I cannot prepare a meaningful external PR against the public repository. If that source is mirrored or contributions are accepted elsewhere, I would be happy to turn this into a focused patch and regression test.

Follow-up after testing external workaround options on the same machine and app build:

I do not recommend publishing or installing an external helper for this issue. The user-side approaches I tested were not reliable across displays/Spaces.

Environment:

• macOS 26.5 (25F71)
• Apple Silicon arm64
• Codex/ChatGPT App 26.707.61608, CFBundleVersion 5200

Observed results:

• A same-display focus bounce could sometimes restore the caret and Chinese input, but it caused a visible focus flicker.
• When the Pet notification was clicked while working on the second display, the composer still had no caret and Chinese input remained unavailable.

External mechanisms tested:

1. NSRunningApplication.activate(options: [.activateAllWindows])
2. NSWorkspace.openApplication through LaunchServices
3. A standard kAEReopenApplication Apple Event
4. Repeated activation coordinated with NSWorkspaceActiveSpaceDidChangeNotification
5. An Accessibility-authorized helper that synthesized a complete Command-Tab sequence and waited for real NSWorkspace activation notifications before returning

In the final Accessibility test, the helper observed a non-Codex application become active and then observed Codex become active again, but the composer still had no caret and could not accept Chinese input until a physical manual app switch was performed.

Because the workaround required broad Accessibility permission, caused visible focus switching, and still failed on the second display, I did not publish the proposed helper repository. This evidence reinforces that the reliable fix needs to live inside the desktop app: the Pet notification path should use the same strong macOS activation path as the explicit focus path, including app.focus({ steal: true }), BrowserWindow.focus(), webContents.focus(), and composer refocus after an active-Space transition.

Still reproducible on the latest build available on this machine, with an additional deterministic activation path.

Environment

• ChatGPT/Codex desktop: 26.707.72221
• CFBundleVersion: 5307
• macOS: 26.5 (25F71)
• Apple Silicon arm64

Reproduction

1. Wake the floating Pet.
2. Switch to another application/window.
3. Switch back to ChatGPT.
4. Click the primary composer and try to type.

The primary composer cannot obtain keyboard focus and no text can be entered. This path reproduces consistently while the Pet is awake.

Desktop log evidence

At 2026-07-15T01:32:59.704Z, the app reports:

avatarOverlay window=2 focused=true visible=true
primary       window=1 focused=false visible=true

Subsequent events continue to report the Pet overlay as focused while the visible primary window remains unfocused. Focus is restored after the Pet is tucked away.

This suggests that macOS app reactivation can restore key focus to avatarOverlay instead of the primary window/composer. In addition to strengthening the Pet notification open path, it may be worth handling did-become-active: if the Pet has no active keyboard interaction, restore the last active primary window and its WebContents/composer focus. Similarly, when Pet keyboard interaction is disabled while the overlay owns focus, focus should be returned to the primary window.

Workaround

Tuck away the Pet or restart the app.