Codex Desktop pet/avatar overlay renders tray but not mascot sprite

Date observed: May 12, 2026

Environment:

• Windows desktop app installed from Microsoft Store
• MSIX package identity: OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
• Internal app package version from extracted package.json: 26.506.31421

Summary

The Avatar / pet overlay opens and the activity bubble or status tray renders, but the mascot sprite itself is invisible. In addition, the tray can be partially clipped or incomplete depending on the saved overlay position.

This reproduces with both built-in pets and custom pets, so it does not look like a custom pet packaging problem.

During local debugging, Codex was able to make the pet render in a patched runtime. That strongly suggests the pet assets themselves are valid, and that the root cause is more likely in Codex Desktop overlay layout, clipping, or scaling behavior.

Actual behavior

• Appearance > Avatar is enabled
• the overlay opens
• activity/status bubbles render
• the selected pet name updates correctly
• the mascot sprite does not appear
• the bubble/tray can render clipped or incomplete

Expected behavior

• the selected pet mascot should be visible and animated
• the bubble/tray should render fully without clipping

Reproduction notes

Observed on Windows with the Store build above.

The issue survived all of the following:

• restarting Codex
• switching between built-in and custom pets
• moving the overlay back toward the center of the screen
• changing custom pet sprites from webp to png
• resetting avatar-related state values

Additional finding from the Codex-led local investigation:

• after launching a patched local runtime, the mascot became visible
• this makes a scaling / DPI / overlay viewport calculation bug more likely than a pet asset bug
• the user-observed symptom was consistent with this: the tray could be visible while the mascot area looked clipped or missing

Local state during reproduction

From C:\Users\admin\.codex\.codex-global-state.json:

• selected-avatar-id: custom:reze
• electron-avatar-overlay-open: true
• electron-avatar-overlay-bounds present and centered

Example centered bounds when the issue was still present:

{
  "x": 760,
  "y": 320,
  "width": 356,
  "height": 320,
  "anchor": { "x": 1008, "y": 545, "width": 80, "height": 87 },
  "mascot": { "left": 248, "top": 225, "width": 80, "height": 87 },
  "placement": "top-end",
  "tray": { "left": 52, "top": 153, "width": 276, "height": 68 }
}

This suggests the problem is not only “overlay saved off-screen”. Even after recentering, the tray was visible while the mascot remained missing.

Why this does not look like a pet asset problem

• the overlay container renders
• the tray/status UI renders
• the selected pet id updates correctly
• built-in and custom pets both show the same failure mode
• Codex was able to get the pet to render in a patched runtime during debugging

That points more toward an Avatar overlay rendering bug than a broken custom pet bundle.

Local source inspection of the installed app bundle

Installed package path:

C:\Program Files\WindowsApps\OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0\app\resources\app.asar

Relevant extracted files:

• webview/assets/avatar-overlay-page-DfAMN2nA.js
• webview/assets/codex-avatar-3lugTYD3.js
• webview/assets/codex-avatar-D82knaKt.css
• webview/assets/index-Bo28oi3C.js
• webview/index.html

Findings:

1. avatar-overlay-page-DfAMN2nA.js imports codex-avatar-3lugTYD3.js.
2. codex-avatar-3lugTYD3.js renders the sprite as a div using backgroundImage.
3. codex-avatar-D82knaKt.css exists and contains the expected sprite sizing rules for .codex-avatar-root.
4. The build dependency graph in index-Bo28oi3C.js references both the avatar JS chunk and the avatar CSS chunk.
5. Even so, the runtime symptom is still “tray visible, mascot invisible”, so either:
   • the avatar CSS is not effectively applied in the overlay runtime,
   • the mascot element exists but paints with zero or invalid effective size,
   • or the mascot is positioned/clipped incorrectly inside the overlay viewport.

Strong conclusion: scaling / default window size bug

The latest local result makes scaling-related behavior the strongest explanation.

Codex was able to make the pet visible in a patched runtime, and the user observed that the pet appeared only when the test runtime happened to open at a smaller window size. In that same state, the bubble also became smaller and rendered more correctly.

By contrast, the stock Store build consistently starts at a larger default window size on this machine, and in that state the tray can be clipped while the mascot is missing.

This makes the most likely root cause:

• Codex Desktop overlay layout or clipping is sensitive to UI scaling, DPI, or effective window size
• the default startup size used by the Store build can place the mascot outside the visible overlay area
• there does not appear to be an exposed setting to lock or override that UI size behavior

Local patch attempts

I tried patching the extracted app locally to test the rendering theory:

• injected explicit inline sprite sizing/background styles into codex-avatar-3lugTYD3.js
• enlarged and repositioned the default overlay viewport and tray layout in avatar-overlay-page-DfAMN2nA.js
• injected a fallback .codex-avatar-root style block into webview/index.html

Those patches were intended to force the mascot to paint even if CSS chunk loading was failing.

Why local patching could not be fully validated

The Microsoft Store build appears to enforce archive integrity for app.asar.

Launching a patched app.asar failed with:

[FATAL:electron\shell\common\asar\asar_util.cc:143] Integrity check failed for asar archive

So I could not directly validate the patched overlay inside the signed Store runtime.

Related public issues

• #21065: overlay/status tray visible but no pet mascot
• #21088: activity bubbles render but avatar sprite is invisible
• #20828: pet can appear half-cropped when summoned
• #21501: /pet renders correctly only in some positions, with clipping/corruption elsewhere

Suggested direction

This looks like an upstream Desktop Avatar overlay regression affecting scaling, clipping, and mascot visibility on Windows.

The most useful fixes to investigate would likely be:

• verifying whether the avatar CSS chunk is applied inside the overlay webview at runtime
• checking computed size/paint of .codex-avatar-root
• checking overlay clipping and mascot bounds restoration logic separately from tray bounds restoration
• checking whether the default startup window size or Windows display scaling changes the effective mascot bounds and causes clipping or zero-visibility rendering