Desktop update prompt should show target versions, component diff, and environment impact #23053

Summary

Codex Desktop currently surfaces a blue in-app update button / Microsoft Store update state without telling the user what they are updating from, what they are updating to, which Codex layers will change, or whether the update is likely to affect known issues on their platform.

For a coding agent platform, this is a risky and opaque update UX. Desktop updates are not just cosmetic Electron updates: the Store package can also replace the bundled native Codex agent/app-server, WSL/Linux payload, helper binaries, and bundled plugins. The UI should make that visible before the user clicks update.

Why this matters

A Desktop user may be trying to decide whether to take an update while debugging active app/runtime issues. Today the update affordance gives no actionable context:

• no current installed Store/AppX package version
• no current Electron app version
• no current Electron runtime version
• no current bundled Windows agent/app-server version
• no current bundled WSL/Linux agent/app-server version
• no bundled plugin version info
• no pending target versions
• no release notes for the pending Desktop bundle
• no indication whether this is Electron-only, agent/runtime-changing, plugin-changing, or all of the above
• no warning that active sessions/app-server processes may need a full restart
• no surfaced known issues that may affect the current platform/configuration

This makes the update button a mystery button.

Concrete example

On a Windows Desktop + WSL setup, the UI showed an update available. To understand what it would do, I had to do all of the following manually:

1. Query the installed Store package with PowerShell Get-AppxPackage OpenAI.Codex.
2. Inspect the installed package under C:\Program Files\WindowsApps\OpenAI.Codex_<version>....
3. Parse app/resources/app.asar to read the Electron app package.json.
4. Read app/version for the Electron runtime line.
5. Check the Desktop-managed WSL agent binary under %USERPROFILE%\.codex\bin\wsl\codex.
6. Inspect bundled resources including codex.exe, codex, node_repl.exe, rg.exe, codex-command-runner.exe, codex-windows-sandbox-setup.exe, and bundled plugins.
7. Fetch the official production update manifest from https://persistent.oaistatic.com/codex-app-prod/windows-store-update.json.
8. Locate a pending MSIX package externally, download it, and inspect it read-only without installing it.
9. Parse the pending MSIX AppxManifest.xml, app/version, and app/resources/app.asar.
10. Use binary string inspection to infer the bundled Codex CLI/app-server version without executing downloaded binaries.
11. Compare the inferred bundled CLI version against openai/codex release tags and merged PRs, because the public changelog does not cover these minor Desktop bundles in enough detail.
12. Scan the current and pending app bundles for code-path indicators related to existing platform issues, such as default project root behavior, WSL CODEX_HOME behavior, helper/arg0 behavior, bundled Chrome plugin version, and plugin vendor_imports behavior.

That amount of reverse-engineering should not be required to decide whether to click an official update button.

Expected UX

Before installing, the update UI should show something like:

Current install
- Store package: <current AppX package version>
- Desktop app: <current Electron app version>
- Electron runtime: <current Electron runtime version>
- Windows agent/app-server: <current bundled or active version>
- WSL/Linux agent/app-server: <current bundled or active version>
- Bundled plugins changed: <yes/no, key plugin versions>

Pending update
- Store package: <pending AppX package version>
- Desktop app: <pending Electron app version>
- Electron runtime: <pending Electron runtime version>
- Windows agent/app-server: <pending bundled version>
- WSL/Linux agent/app-server: <pending bundled version>
- Bundled plugins changed: <yes/no, key plugin versions>

What changes
- Component-level changelog grouped by Desktop app, CLI/app-server, WSL/runtime, plugins, sandbox/helpers.
- Links to exact release notes or generated PR ranges.

Known impact for this environment
- This update changes the native agent/runtime: yes/no.
- This update requires a full Desktop/app-server restart: yes/no.
- Relevant known issues for Windows/WSL/Chrome/plugin/sandbox/etc.
- Whether the update is known to fix, not fix, or possibly affect those issues.

Recommendation
- Net gain likely / mixed / regression risk, based on known issues and component changes.

Feature request

Please make Desktop update metadata first-class:

1. Publish a machine-readable Desktop release manifest that includes all layer versions, not only the Store package version.
2. Include bundled CLI/app-server versions for each platform payload.
3. Include bundled plugin versions and whether they changed.
4. Include component-level release notes for Desktop app, app-server/CLI, WSL/runtime helpers, sandbox, and plugins.
5. Add an in-app "What changes?" view next to the update button.
6. Add a post-update verification summary after relaunch showing which versions are now active.
7. Surface known platform-specific issues or warnings when they match the user's environment, e.g. Windows + WSL, OneDrive-backed project roots, Chrome plugin state, sandbox setup, or stale helper/app-server state.
8. Provide enough metadata for local tooling to score whether the update is likely a net gain or a regression risk for the current host.

Related implementation idea

The app already appears to know or be able to derive most of this:

• Store/AppX package identity from Windows package APIs.
• Electron app version and build metadata from packaged app metadata.
• Electron runtime from packaged resources.
• Bundled native agent payloads from package resources.
• Official Store update target from the OpenAI update manifest.
• Bundled plugins from packaged plugin metadata.
• Active app-server/CLI version from the runtime binary.

The missing piece is exposing this in a single supported, user-visible, machine-readable place instead of requiring package forensics.

Safety note

Users should not need to execute downloaded package binaries or inspect third-party mirrors to determine what the official update button will do. The official app should expose the target versions and expected impact directly.