Windows Store updates reset Codex taskbar-corner / tray visibility preference
Summary
After a Microsoft Store update, Codex's Windows taskbar-corner / system-tray visibility preference is treated as a new app and the icon can return to the overflow menu, even when the user previously chose to keep it visible.
Reproduction
- Install Codex Desktop from the Microsoft Store.
- In Windows taskbar settings, configure Codex to remain visible in the taskbar corner.
- Install a Codex update from the Microsoft Store.
- Launch the updated app.
- Observe that the tray icon may be placed back in the overflow menu and the preference must be set again.
Expected behavior
The user's taskbar-corner visibility choice should survive a normal Codex update.
Actual behavior
The update creates a new notification-area identity, so Windows does not reliably carry the previous visibility preference forward.
Evidence
The Microsoft Store install uses versioned MSIX package paths. Windows notification-area settings contain separate Codex records for distinct package versions, for example:
OpenAI.Codex_26.707.3748.0_x64__...\\app\\ChatGPT.exe
OpenAI.Codex_26.707.8168.0_x64__...\\app\\ChatGPT.exe
This strongly suggests that the tray identity presented to Windows changes across upgrades.
Suggested direction
Preserve a stable Windows tray identity across MSIX upgrades (for example, a stable AppUserModelID and/or tray icon GUID) so Windows can retain the user's existing notification-area preference.
Why this matters
This is a small but recurring update regression: users lose an explicit Windows preference after every app update. Fixing it proactively would avoid a common problem seen in comparable desktop coding apps.
3 Comments
Additional confirmation from another affected installation:
C:\Program Files\WindowsApps\OpenAI.Codex_26.715.9079.0_x64__2p2nqsd0c76g0\app\resources\codex.exe^overflow is hidden there again.A concrete implementation path, if this tray is created through Electron, is to pass one hard-coded, version-independent UUID as the second argument to
new Tray(image, guid)and keep it unchanged across releases. It should not be derived from the package version, package install path, or app version. Electron documents that for a signed Windows executable, this GUID is associated with the signature and OS-level settings such as tray position persist even when the executable path changes:https://www.electronjs.org/docs/latest/api/tray/#new-trayimage-guid
This also matches the native Windows model: Microsoft recommends identifying a notification icon by
guidItemrather thanhWnd + uID:https://learn.microsoft.com/en-us/windows/win32/api/shellapi/ns-shellapi-notifyiconidentifier#remarks
Suggested acceptance test:
Existing users may need to promote the icon once after the stable GUID first ships; subsequent upgrades should then retain that preference.
Confirmed on Windows 11 23H2. After each Codex Microsoft Store update, the tray icon is placed back in the hidden-icons overflow even though it had previously been explicitly configured to remain visible. Manually promoting the icon fixes it only until the next Codex update.
This is repeatable across updates and appears consistent with the tray identity changing between versioned MSIX package installations. The visibility preference should survive normal application upgrades.
@CxMYu, could you please reopen this issue? It is still reproducible on the current Windows Store build.
Fresh confirmation from the same Windows 10 Pro 22H2 installation:
OpenAI.Codex_26.727.6591.0_x64OpenAI.Codex_26.730.8199.0_x64^overflow.There is no linked PR, commit, or released-fix reference in this issue, and the behavior persists on
26.730.8199.0. This appears to remain an active update regression rather than a completed or obsolete report.