What version of the Codex App are you using (From “About Codex” dialog)?
Windows Store / AppX package: OpenAI.Codex_26.810.7004.0_x64__2p2nqsd0c76g0.
The in-app About string was not captured; the package version above was read from Get-AppxPackage OpenAI.Codex.
What subscription do you have?
Not relevant to this local UI rendering issue.
What platform is your computer?
- Windows 11 Home China
- Microsoft Windows NT
10.0.26200
- Build
26200
- x64
What issue are you seeing?
While a floating Codex Pet is being dragged, a bright cyan rectangular frame appears around the full transparent avatar-overlay window.
The rectangle is much larger than the visible mascot and matches the overlay viewport bounds, so it is not an outline in the pet artwork or the sprite's alpha edge.
This did not happen previously. It still reproduces after uninstalling a locally modified Viri package and reinstalling the unmodified original Viri demo package.
The installed package is a standard v2 custom pet:
{
"id": "viri",
"displayName": "Viri",
"spriteVersionNumber": 2,
"spritesheetPath": "spritesheet.webp"
}There is no border or drag-visualization setting in pet.json.
What steps can reproduce the bug?
- Install/select the standard Viri v2 custom Pet.
- Wake/show the floating Pet overlay on Windows.
- Press the primary mouse button on the Pet and drag it.
- Observe the cyan rectangular frame around the entire transparent overlay window while dragging.
- Release the pointer.
- Uninstall the Pet, reinstall the unmodified original Viri demo package, and repeat. The same frame still appears.
What is the expected behavior?
Dragging should move the Pet without exposing the bounds of the transparent host window. Only the mascot and its normal overlay controls should be visible.
What is the actual behavior?
The full avatar-overlay window bounds become visible as a cyan frame during dragging.
A screenshot has been captured and can be attached in a follow-up if needed.
Additional information
This appears to be a Windows avatar-overlay host regression rather than a custom-pet asset problem:
- The frame encloses the full transparent overlay viewport, not the sprite content.
- Reinstalling the unmodified original demo package does not change the behavior.
- The packaged app routes dragging through the native
performOverlayWindowDrag path and publishes avatar-overlay-window-drag-state-changed.
- The renderer bundle also contains an
avatar-overlay-debug-window-border-visible flag whose default is false. Its renderer visualization is a red 2 px outline, while the observed frame is cyan, and no persisted value for that flag was found in the normal Codex state or Chromium local storage.
The most likely affected area is therefore the Windows native avatar-overlay drag/composition path: native window dragging appears to temporarily expose a DWM/system-accent window frame or otherwise change the transparent frameless overlay's window styling.
Possible fix directions:
- Keep the avatar overlay frameless and non-bordered throughout native drag/mouse capture.
- Ensure
performOverlayWindowDrag does not temporarily apply a standard/focused DWM frame.
- Add a Windows regression test that drags both a built-in Pet and a valid v2 custom Pet and verifies that no host-window outline is painted.
I searched open and closed issues for Pet drag bounding boxes, cyan outlines, and avatar-overlay window borders and did not find an exact duplicate.
Related but distinct:
Resolution update
Closing this report because the same outline also appears when dragging an unrelated WispScience application window on the same machine. The outline color changes with the background (for example, it appears white on black), so the earlier description of a fixed cyan Codex overlay border and the Codex-specific root-cause inference were incorrect.
This is now more consistent with a local Windows/DWM, graphics-composition, accessibility, or window-drag visualization setting than with the Codex Pet renderer or custom-pet source package. The original unmodified Pet repository should therefore not be treated as the cause.
Confirmed local cause
The local Windows setting is:
HKCU\\Control Panel\\Desktop\\DragFullWindows = 0
This disables “Show window contents while dragging” and makes Windows draw a contrast-dependent window outline during native window dragging. The same behavior in WispScience is therefore expected from the same local setting. This is not a Codex or Pet source-code defect.
What version of the Codex App are you using (From “About Codex” dialog)?
Windows Store / AppX package:
OpenAI.Codex_26.810.7004.0_x64__2p2nqsd0c76g0.The in-app About string was not captured; the package version above was read from
Get-AppxPackage OpenAI.Codex.What subscription do you have?
Not relevant to this local UI rendering issue.
What platform is your computer?
10.0.2620026200What issue are you seeing?
While a floating Codex Pet is being dragged, a bright cyan rectangular frame appears around the full transparent avatar-overlay window.
The rectangle is much larger than the visible mascot and matches the overlay viewport bounds, so it is not an outline in the pet artwork or the sprite's alpha edge.
This did not happen previously. It still reproduces after uninstalling a locally modified Viri package and reinstalling the unmodified original Viri demo package.
The installed package is a standard v2 custom pet:
{ "id": "viri", "displayName": "Viri", "spriteVersionNumber": 2, "spritesheetPath": "spritesheet.webp" }There is no border or drag-visualization setting in
pet.json.What steps can reproduce the bug?
What is the expected behavior?
Dragging should move the Pet without exposing the bounds of the transparent host window. Only the mascot and its normal overlay controls should be visible.
What is the actual behavior?
The full avatar-overlay window bounds become visible as a cyan frame during dragging.
A screenshot has been captured and can be attached in a follow-up if needed.
Additional information
This appears to be a Windows avatar-overlay host regression rather than a custom-pet asset problem:
performOverlayWindowDragpath and publishesavatar-overlay-window-drag-state-changed.avatar-overlay-debug-window-border-visibleflag whose default isfalse. Its renderer visualization is a red 2 px outline, while the observed frame is cyan, and no persisted value for that flag was found in the normal Codex state or Chromium local storage.The most likely affected area is therefore the Windows native avatar-overlay drag/composition path: native window dragging appears to temporarily expose a DWM/system-accent window frame or otherwise change the transparent frameless overlay's window styling.
Possible fix directions:
performOverlayWindowDragdoes not temporarily apply a standard/focused DWM frame.I searched open and closed issues for Pet drag bounding boxes, cyan outlines, and avatar-overlay window borders and did not find an exact duplicate.
Related but distinct:
Resolution update
Closing this report because the same outline also appears when dragging an unrelated WispScience application window on the same machine. The outline color changes with the background (for example, it appears white on black), so the earlier description of a fixed cyan Codex overlay border and the Codex-specific root-cause inference were incorrect.
This is now more consistent with a local Windows/DWM, graphics-composition, accessibility, or window-drag visualization setting than with the Codex Pet renderer or custom-pet source package. The original unmodified Pet repository should therefore not be treated as the cause.
Confirmed local cause
The local Windows setting is:
This disables “Show window contents while dragging” and makes Windows draw a contrast-dependent window outline during native window dragging. The same behavior in WispScience is therefore expected from the same local setting. This is not a Codex or Pet source-code defect.