[Windows][26.820.9563.0] Packaged activation shows no UI on non-system AppX volume; moving app to C: fixes it

Summary

Codex Desktop / ChatGPT for Windows OpenAI.Codex 26.820.9563.0 could be installed and updated on a non-system AppX volume (D:\WindowsApps), but launching through the Start menu / AppUserModelID produced 5–6 responsive ChatGPT.exe processes with no top-level window. Directly launching the exact same packaged executable from D:\WindowsApps\...\app\ChatGPT.exe created the UI normally.

Moving the package using Windows' supported AppX Move operation from D: to the system AppX volume C: immediately restored normal Start-menu packaged activation. No application-data reset was required.

This looks like a packaged-activation regression/compatibility issue when Codex is installed on a non-system AppX volume.

Environment

• Windows x64
• Windows build observed in AppX deployment stack: 10.0.26100.9168 / related components 10.0.26100.8972
• Codex package: OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0
• Codex version: 26.820.9563.0
• AppUserModelID: OpenAI.Codex_2p2nqsd0c76g0!App
• Manifest application entry:
• Id=App
• Executable=app/ChatGPT.exe
• EntryPoint=Windows.FullTrustApplication
• System AppX volume: C:\Program Files\WindowsApps
• Non-system AppX volume: D:\WindowsApps
• D: was configured as the default AppX/new-app volume before troubleshooting.

Reproduction / observed behavior

With the package on D::

1. Launch from Windows Start menu, or explicitly run:

explorer.exe shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App

1. 5–6 ChatGPT.exe processes start.
2. Processes report Responding=True, but every process has MainWindowHandle=0 and empty MainWindowTitle.
3. No UI appears.
4. Kill those processes.
5. Directly run:

D:\WindowsApps\OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe

1. UI appears normally. In one captured run the main process had a nonzero MainWindowHandle (265918) and title ChatGPT.

Thus the executable/payload itself was usable; the failure was specific to packaged/AppUserModelID activation while the package resided on the non-system AppX volume.

AppX evidence

Get-AppxVolume showed both volumes online:

• C: IsSystemVolume=True
• D: IsSystemVolume=False

AppX deployment logs during troubleshooting explicitly reported:

• OpenAI.Codex... is already on the target volume, therefore it will not be moved when D: was selected.
• ACL repair against \\?\D:\WindowsApps\OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0 succeeded.
• Windows also referred to a package-root junction under C:\Program Files\WindowsApps\OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0.
• A repair/register attempt while Codex was running failed with 0x80073D02 (application needed to be closed); after closing it, registration completed with result 0x0 but packaged activation still showed no UI on D:.

Workaround / confirmation

The Windows setting for new applications was changed from D: to C:. Then Codex was moved using the supported Windows Installed Apps / AppX Move operation to C:.

Deployment log confirmed:

• MovePackageOperation with target volume C: completed successfully.
• Registration with target volume C: completed successfully.
• Package status: Ok.

Immediately afterward, launching ChatGPT from the same Start-menu entry produced the UI normally.

No reset of Codex local application data was necessary.

Expected behavior

If Codex permits installation/movement to a registered non-system AppX volume, Start-menu/AppUserModelID activation should behave the same as it does on the system volume. Otherwise, if Codex requires the system volume, the package should declare/enforce that restriction so Windows does not allow installation/movement to D:.

Actual behavior

On D: the packaged activation path starts multiple responsive processes but creates no visible window; direct executable launch works. Moving the package to C: fixes packaged activation immediately.

Additional context

The issue appeared after an update to 26.820.9563.0. During troubleshooting, CLI staging was verified separately and a local codex.exe existed under %LOCALAPPDATA%\OpenAI\Codex\bin\...; the final UI failure did not require modifying CLI paths or resetting user/project data.

This report contains only diagnostic/system information relevant to reproduction; no project contents, credentials, tokens, or private application data are included.