›_ Codex Issues
Codex Issues / #23163

Pet overlay forces macOS to auto-switch back to Codex's Space when navigating to another Space

Open 💬 2 comments Opened May 17, 2026 by REXKEV214

What platform is your computer?

macOS (Darwin 25.5.0)

What issue are you seeing?

After waking the Codex pet, navigating to any other macOS Space causes the system to immediately auto-switch back to the Space where Codex's main window lives. Every attempt to focus another Space yanks me back to Codex within ~1–2 seconds, making multi-Space workflow impractical while the pet is awake.

Observations from a screen recording of the repro (attached as a comment):

  • The pet sprite is visible on every Space, consistent with canJoinAllSpaces-style window behavior.
  • Switching to a Space that contains only a Finder window still triggers the auto-switch back.
  • The trip back happens fast enough that it interrupts the Mission Control transition animation.

Hypothesis: the pet overlay is not actually a fully non-activating panel, so when it animates / gains focus / receives input on the new Space, it activates the Codex app process. macOS then applies the "When switching to an application, switch to a Space with open windows for the application" rule (System Settings → Desktop & Dock → Mission Control) and slides back to Codex's home Space.

This may share a root cause with #20706, which logs NSWindow does not support nonactivating panel styleMask 0x80 — suggesting the intended non-activating mask is not being applied on macOS. See also #20831 for an unrelated but pet-overlay-adjacent issue.

What steps can reproduce the bug?

  1. On a multi-Space macOS setup (e.g. 6 Spaces), assign Codex's main window to one Space.
  2. Wake the pet with /pet.
  3. Switch to a different Space that does not contain Codex's main window — via Mission Control, swipe, or Ctrl+arrows. A Space with only a Finder window is enough.
  4. Within ~1–2 seconds, macOS automatically slides back to Codex's home Space.

What is the expected behavior?

Switching to another Space should stay on that Space. The pet overlay should never implicitly reactivate the Codex app or trigger Spaces switching when the user navigates away.

Additional information

  • macOS Spaces: 6 Spaces, Codex pinned to one of them; pet overlay floats on all Spaces.
  • Likely-related setting: System Settings → Desktop & Dock → Mission Control → "When switching to an application, switch to a Space with open windows for the application". Disabling this may be a workaround, but the overlay should not be triggering app activation in the first place.
  • Screen recording reproducing the bug will be attached as a comment.

View original on GitHub ↗

2 Comments

REXKEV214 · 3 months ago

Attached: screen recording of repro #

https://github.com/user-attachments/assets/a3e1e0fe-4631-4200-bcb8-028ef08320f7

KorenKrita · 1 month ago

I can reproduce this on a current Codex Desktop build, and captured the macOS application/Space activation sequence. This provides direct evidence that the pet overlay causes Codex to reactivate.

Environment

  • Codex Desktop: 26.715.61943
  • CFBundleVersion: 5628
  • Bundle ID: com.openai.codex
  • macOS: 26.5.2 (25F84)
  • Apple Silicon
  • Target application in the reproduction: Ghostty 1.3.2-main-+ea7dc5c00

Reproduction

  1. Keep the Codex main window on Space 1.
  2. Show/wake the Codex pet.
  3. Put Ghostty on another normal Space.
  4. Start from Chrome on Space 1.
  5. Use Cmd-Tab to select Ghostty.
  6. Ghostty's Space appears briefly, then macOS returns to the Space containing Codex.

Direct trackpad navigation to the Ghostty Space works normally. The failure occurs when switching to Ghostty through Cmd-Tab.

Captured activation sequence

A standalone AppKit probe observed NSWorkspace activation notifications and sampled the managed Space ID every 25 ms:

+17.698s  APP_ACTIVATE    Ghostty | com.mitchellh.ghostty
+17.699s  APP_DEACTIVATE  Google Chrome | com.google.Chrome
+17.703s  FRONT_SAMPLE    Ghostty
+17.988s  APP_ACTIVATE    ChatGPT/Codex | com.openai.codex
+17.988s  APP_DEACTIVATE  Ghostty
+18.006s  FRONT_SAMPLE    ChatGPT/Codex
+18.006s  SPACE_SAMPLE    Space 8, front=ChatGPT/Codex
+18.458s  SPACE_SAMPLE    Space 1, front=ChatGPT/Codex

Codex reactivated approximately 290 ms after Ghostty became active. The Space switched back only after com.openai.codex became frontmost.

The source application was Chrome, but Codex—not Chrome—became active after Ghostty. This rules out macOS merely restoring the previous/source application.

Controls

  • Reproduces with exactly one Ghostty window and one terminal/tab.
  • Reproduces after fully quitting Hammerspoon.
  • Reproduces when switching from Chrome to Ghostty.
  • Minimizing the Codex main window prevents the problem.
  • More specifically, hiding only the Codex pet fixes the problem while the Codex main window remains visible.
  • Showing the pet again restores the failure.

This isolates the behavior to the avatar/pet overlay rather than the Codex main window, Ghostty, or a third-party hotkey/window manager.

Packaged component observation

The installed app contains:

Contents/Resources/native/avatar-overlay.node

Its Objective-C symbols include:

NSPanel
petEffectWindow
activityStackInteractionWindow
pendingActivationWindow
keyboardTargetWindow
canBecomeKeyWindow
makeKeyWindow
setCollectionBehavior:
setLevel:

That is consistent with the issue hypothesis: an avatar overlay NSPanel or pending activation window is becoming key/active during the cross-Space transition, causing com.openai.codex to reactivate and Mission Control to return to Codex's home Space.

Workaround

Hide the Codex pet. The main Codex window can remain visible; it does not need to be minimized or quit.