Windows Store app exits silently (code 0) when launched with no command-line arguments; launches fine with any argument

## Summary

On a fresh install of the Codex/ChatGPT unified Windows app from the Microsoft Store, launching the app normally (Start-menu tile) causes the main ChatGPT.exe process to start, spawn its crashpad handler, and then exit cleanly (exit code 0) within ~2 seconds. No window ever appears, and there is no error dialog, no Event Log entry, no WER report, no crash dump, and no stdout/stderr output. From the user's perspective the app simply does nothing (on the first launch after install it appeared to open a tab in the default browser, then nothing on subsequent launches).

The same binary launches perfectly — window appears, signs in, fully functional — if it is started with any command-line switch, including a completely unknown/no-op one. The presence or absence of arguments is 100% correlated with success/failure across ~10 trials.

• Launched with no args (Start tile / shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App / direct ChatGPT.exe): 0 for 5 — always exits with code 0 in ~2 s
• Launched via codex:// protocol activation: also exits silently
• Launched with --enable-logging --v=1: works
• Launched with --disable-features=NonexistentDummyFeature (a no-op): works (3 for 3 with any argument)

Note this is effectively a heisenbug for logging: --enable-logging itself makes the failure disappear, so no chrome_debug.log can be captured for a failing run. Capturing stdout/stderr of a failing no-arg run yields 0 bytes; cmd /c reports ERRORLEVEL 0.

Environment

• App: OpenAI.Codex 26.803.5235.0 x64 (Microsoft Store, product 9PLM9XGG6VKS), fresh install
• Chromium shell version per crashpad annotations: prod=Codex ver=151.0.7922.76
• OS: Windows 11 Enterprise 10.0.22631 (23H2), enterprise-managed (domain policies present; Chrome enterprise policies force-install extensions, which the app's Chromium shell also picks up)
• Display: single monitor, 2560x1440, scale factor 1 (so not the known off-screen/DPI window bug)
• Default browser: Google Chrome
• The legacy OpenAI.ChatGPT-Desktop ("ChatGPT Classic") Store app is also installed

Steps to reproduce

1. Install the app from the Microsoft Store (winget install --id 9PLM9XGG6VKS -s msstore).
2. Launch it from the Start menu (or explorer shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App).
3. Observe: ChatGPT.exe and its --type=crashpad-handler child appear in Task Manager for ~2 seconds, then exit. No window. Exit code 0.
4. Now launch the same exe with any argument, e.g.:

``powershell
Invoke-CommandInDesktopPackage -PackageFamilyName "OpenAI.Codex_2p2nqsd0c76g0" -AppId "App"
-Command "C:\Program Files\WindowsApps\OpenAI.Codex_26.803.5235.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe"
-Args "--disable-features=NonexistentDummyFeature"
``

1. Observe: app launches fully and works (12 processes, visible window, loads chatgpt.com, authenticated session works).

Diagnostics already ruled out

• Not a crash: no WER reports, no Event Log entries, no Crashpad dumps (Crashpad\reports empty), exit code 0 — it is a deliberate clean exit on the no-arg code path.
• Not the legacy ChatGPT Classic app interfering: killing all ChatGPT Classic.exe processes before a no-arg launch makes no difference.
• Not stale profile state: fresh install; no pre-existing %APPDATA%\Codex; the redirected LocalCache\Roaming\Codex was created new at first launch. (A ~/.codex directory from prior Codex CLI/app usage does exist.)
• Not the off-screen/no-window bug (bswen writeup): in the failing case the process fully exits; in the working case the window is created on-screen and visible.
• Window enumeration in the working case shows the visible main window (Chrome_WidgetWin_1, title "ChatGPT") plus a hidden "Codex" window — all normal.

Possibly related observation from a working (logged) run

The Electron/owl renderer logs this on startup:

ERROR:owl\browser\api\electron_api_web_contents.cc] Electron renderer console [warning]
app://-/assets/app-initial-*.js Matched leaf route at location "/" does not have an element or
Component. This means it will render an <Outlet /> with a null value by default resulting in an
"empty" page.

If the no-arg startup path decides visibility/exit based on whether initial content rendered, an empty route at / could explain a "nothing to show → exit 0" outcome, while any CLI switch may route startup through a different branch. Speculative — included only as a lead.

Workaround

A shortcut that launches app\ChatGPT.exe inside the package context (Invoke-CommandInDesktopPackage) with a dummy switch makes the app fully usable.

Expected behavior

Launching the app from the Start menu (no arguments) should open the app window.