Pet overlay window extends offscreen after 26.901 update — constrainNativeDrawWindowToDisplay is win32-only, pet invisible on macOS multi-display setups

Environment

• Codex App version: 26.901.51231 (Build 8109) — auto-updated from 26.831.20005 on Sep 6, ~11:38 local time
• macOS: 15.6 (Darwin 24.6.0, arm64)
• Displays: MacBook built-in display + external display arranged above it; Mission Control option "Displays have separate Spaces" enabled

Symptom

Since the 26.901 auto-update, the desktop pet is invisible on both screens. If I manage to drag it back onto the built-in display, it disappears again shortly after. Before the update (26.831), the pet worked fine for weeks on the same hardware and display arrangement.

Root cause analysis (from the shipped app.asar)

The 26.901 update enabled the new native layout engine for the pet overlay (the one backing the Quick Chat input bar, realtime caption bubbles, and the docked PIP drawer). Tracing the shipped bundle:

1. In native mode the draw window is sized to the tallest display in the setup — in my case a 3759px-tall window — and positioned so its top edge extends into negative Y coordinates above the built-in display.

2. The bounds-clamping flag exists but is hardcoded to Windows only. In the minified bundle of 26.901.51231, the call site passes:

   constrainNativeDrawWindowToDisplay: process.platform === `win32`
   

   (the layout helper's parameter defaults to false). The clamp path appears to be well-tested on Windows, where pets driven by the same engine stay on screen.

3. On macOS the window is never clamped, so its top region crosses into the external display's bounds. With "Displays have separate Spaces" enabled, macOS assigns the window to the external display's Space, and the pet becomes invisible and unreachable from the built-in display.

The legacy layout (26.831) requested a compact ~200×200 window whose origin stayed inside the work area, which is why this never showed up before the update.

Suggested fix

Enable the existing clamp on macOS (or remove the platform gate entirely):

constrainNativeDrawWindowToDisplay: true

Alternatively, clamp nativeDrawDisplayHeightPx / the anchor Y against the target display's workArea when computing the native draw window bounds.

Workarounds (for anyone hitting this)

• Disable System Settings → Desktop & Dock → Mission Control → "Displays have separate Spaces" — the pet reappears.
• Or keep the pet near the top-left corner of the built-in display, which is the only position that renders reliably (matches the position-dependent clipping in #21501).

Related

• #21501 — position-dependent pet clipping on macOS (same native-overlay bounds family)
• #41960 — Windows pets unresponsive to drag/click

Start by locating the native layout helper and the shipped app.asar call site where constrainNativeDrawWindowToDisplay is restricted to win32. Reproduce the overlay with macOS 15.6, two displays arranged vertically, and separate Spaces enabled. Done means the pet remains visible and reachable on both displays after the native draw window is constrained.