macOS: Pet control icons separate from native circular backgrounds while dragging

Additional deterministic trigger, code-path evidence, and proposed fix

I can reproduce this reliably by dragging the Pet close to the macOS top edge/menu-bar boundary. At normal positions, the waveform/count glyphs and their native circular backgrounds are concentric. Near the top edge, both native circles remain approximately one menu-bar inset away from the Pet while the Chromium glyphs initially continue moving with the Pet; the glyphs may catch up later.

On this Retina 2x display, the displacement is approximately 78 physical pixels = 39 logical pixels. NSScreen reports a 1329-point full frame and a 1290-point visible frame, also a 39-point difference. This makes the deterministic boundary related to the menu-bar visibleFrame / Electron workArea inset rather than sprite padding or an individual icon's layout.

Build 6119 code-path findings

The installed application bundle contains the relevant Desktop implementation even though it is not present in the public repository source tree:

1. In native mode, getLayoutForDisplay() passes a display rect based on display.workArea, preserving workArea.y as the top bound. The anchor clamp then clamps y to that bound.
2. During native Window Server dragging, moveDrag() skips the renderer-drag path.
3. updateWindowServerDragPlacement() updates the anchor, but if the logical top/bottom placement is unchanged and the update is not final, it returns before recomputing the full layout, calling compositionHost.updateMascotRect(), or sending renderer state.
4. compositionHost.updateMascotRect() also has a separate equality early return. Moving the root window changes its screen origin but does not change the mascot's window-local rect, so merely calling this method again is not necessarily enough to refresh native child-window geometry.
5. The renderer calculates voice-controls and mascot-badge from chromiumPresentationRect relative to the mascot. When native material is attached, the DOM control background is transparent, confirming that the visible circular backing is supplied by a separate native material layer.

The compiled avatar-overlay.node also preserves the relevant Objective-C method names:

• -[AvatarOverlayRootEffectSurface updateVoiceControlsInteractionScreenRect:surfaceRects:... ] independently sets frames for voiceControlsInteractionWindow and voiceControlsGlassWindow.
• -[AvatarOverlayRootEffectSurface windowDragWillBegin] marks the native drag active and stops the current glass-frame animation.
• -[AvatarOverlayRootEffectSurface windowDidMove:] returns while windowDragInProgress is true.
• -[AvatarOverlayCompositionCoordinator updateVoiceControlsPresentationFrames:] later publishes control screen rects to the Chromium surfaces.
• -[AvatarOverlayCompositionSurface applyPetControlsPresentationPositionForScreenRect:] computes the screen-rect center delta and applies transforms separately to the container and Chromium layers.

This sequence explains both parts of the symptom: the root/Chromium windows move past the last work-area-clamped position while the independent native glass frames remain stale, and the glyphs later move again when the native presentation-frame callback applies a corrective transform. The exact 39-point maximum separation is the distance from the last valid work-area origin to the display edge.

Proposed fix

The preferred fix is to give the native glass/interaction windows and Chromium surfaces one canonical screen-space control-rect update per native-drag frame:

1. In AvatarOverlayRootEffectSurface.windowDidMove: (or the existing displayLinkDidFire:), refresh voiceControlsGlassWindow and voiceControlsInteractionWindow from the current root-window screen origin even while windowDragInProgress is true. Expensive wallpaper alignment may remain deferred.
2. Immediately invoke voiceControlsGlassScreenFramesChangedHandler with those same rects so the Chromium presentation surfaces receive the identical geometry in the same display tick.
3. In updateWindowServerDragPlacement(), do not treat an unchanged logical placement as unchanged geometry. If root content bounds or screen origin changed, invoke an explicit native syncWindowGeometry() operation before returning.
4. Do not rely only on updateMascotRect(), because its input is window-local and its equality optimization can suppress the required screen-origin refresh.

A lower-risk temporary workaround would be to disable the Window Server drag path while Pet controls are visible and use the existing moveDragToPointer() -> applyLayout() path, which already applies the work-area clamp and refreshes all layout consumers together.

Suggested regression coverage:

• Drag across workArea.minY and assert on every frame that the native glass-frame center and Chromium presentation-frame center for both voice-controls and mascot-badge differ by less than 0.5 logical pixels.
• Cover Retina/non-Retina, menu-bar auto-hide, external displays, cross-display dragging, and mixed scale factors.
• Unit-test the same-placement branch of updateWindowServerDragPlacement(): changed root bounds must trigger native geometry synchronization.

Public repository check

I checked current openai/codex main at f94b5d899ae8e2785f4f028d35055d4be6b9dca3 (2026-08-03). The repository contains TUI Pet code under codex-rs/tui/src/pets/* and Desktop launcher code under codex-rs/cli/src/desktop_app/*, but not the Electron/native Desktop overlay implementation. Repository-wide searches for AvatarOverlayRootEffectSurface, updateVoiceControlsPresentationFrames, mascot-badge, BrowserWindow, and workArea return no matches. The maintainers will therefore need to map the build-level function and class names above to the internal Desktop source tree.