macOS upgrade removes standalone Codex app before verifying whamAccess entitlement, leaving no GUI access to Codex

What happened

Updating on macOS replaced my working standalone Codex app with the merged ChatGPT desktop app, but my account is not entitled to the unified surface. The result is that Codex is now completely inaccessible in the GUI: the old app was deleted, and the app that replaced it does not show Codex (or Work).

The upgrade removes the user's existing Codex app before confirming the account can actually see Codex in the replacement. For accounts outside the entitlement rollout, this is a strict regression — a working app is destroyed and nothing takes its place.

Environment

• macOS 26.5.2 (25F84), arm64
• ChatGPT.app 1.2026.183 (build 1783607847)
• codex-cli 0.144.1 (unaffected, still works)

Root cause

The app gates the unified surface on a whamAccess flag delivered in the server's account-settings response. The binary reads a flags object whose expected members are visible in ChatGPT.framework:

eclipse
fileLibraryEnabledForRegistrationCountry
bazaarConsentRequired
whamAccess
codexRemoteControl
projectSharing
projectConnectorScopes

The flags object my account actually receives (read from lastAccountSettingsResponse_* in ~/Library/Preferences/com.openai.chat.plist):

{
  "eclipse": false,
  "bazaarConsentRequired": false,
  "fileLibraryEnabledForRegistrationCountry": true
}

whamAccess is never sent. Since Codex and Work share that flag, both are hidden — which matches what I see: the sidebar contains only ChatGPT, Library, GPTs, and Projects.

This is not stale local state. I signed out and signed back in; the app fetched a fresh account-settings response and the flags object was byte-identical, still with no whamAccess.

It is also not a broken install. The Codex UI is fully present in the shipped binary — ChatGPT.framework contains _shouldIncludeCodexInSidebarItems, _codexEnabled, _codexOnlyEnabled, _codexSidebarAboveFold, strings such as Codex Archive List and Codex Branch Selection, and Assets.framework carries the Codex icon and color theme. The code is there and is being told not to render.

Consistently, the Statsig gate chatgpt-macos-codex-upgrade-enabled is absent from my cached payload (so it evaluates false), and the dynamic configs native_macos_app_superapp_download and native_macos_app_superapp_manual_download_url are absent from the 232 configs my client did receive.

Steps to reproduce

1. Have the standalone Codex desktop app installed and working on macOS.
2. Be on an account to which the server does not send whamAccess.
3. Take the 2026-07-10 update.
4. The Codex app is removed from /Applications; the old ChatGPT app is renamed to ChatGPT Classic.app; the new ChatGPT.app shows no Codex and no Work entry.

Expected

The upgrade should verify whamAccess before removing the existing Codex app, and either defer the migration or leave the standalone app in place for accounts not yet in the rollout. Failing that, there should be a documented way to reinstall the standalone Codex app — per the current docs it is no longer offered as a separate download, so an affected user has no supported recovery path.

Actual

Codex is unreachable from any GUI. The only remaining access is codex on the CLI. Recovery required restoring the deleted app bundle from an APFS local snapshot.

Separate defect noticed during diagnosis

ChatGPT.app (1.2026.183) and the ChatGPT Classic.app created by the installer are both signed with the same code-signing identifier, com.openai.chat:

$ codesign -dv "/Applications/ChatGPT.app"          → Identifier=com.openai.chat
$ codesign -dv "/Applications/ChatGPT Classic.app"  → Identifier=com.openai.chat

Two coexisting apps sharing a bundle identifier share a preferences domain, an Application Support directory, and a LaunchServices identity. Since the docs state Classic is expected to remain installed alongside the new app, Classic should almost certainly carry a distinct identifier. Happy to split this into its own issue if preferred.