›_ Codex Issues
Codex Issues / #23053

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

Open 💬 2 comments Opened May 16, 2026 by MisterRound

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.

View original on GitHub ↗

2 Comments

MisterRound · 3 months ago

Adding this incident as a concrete update-safety example.

A useful long-running WSL-backed /goal session was paused specifically to install a Desktop update for remote control/computer-use. Remote control later worked, but the update path exposed several WSL-specific risks that the update prompt did not forecast:

  • Initial launch was blocked by the SQLx migration checksum mismatch in WSL mode: #23777.
  • Computer-use/browser-use was unavailable in WSL mode, and disabling the plugin once failed with a config version conflict; current-build evidence was added to #25194.
  • Bundled plugin cache installation still generated invalid mixed Windows/WSL paths like C:\mnt\c\...; current-build evidence was added to #24268.
  • The old /goal thread had grown a multi-GB rollout and could not be resumed safely after the update; tracked in #25215.
  • The broader Windows Desktop + WSL release-gate gap is tracked in #25216.

This is the kind of state the update flow should detect before prompting a user to upgrade. Suggested preflight checks before update:

  • whether Desktop is configured for WSL app-server mode;
  • whether any /goal jobs or active long-running threads exist;
  • largest rollout file size and whether the target build can stream/compact/recover it;
  • SQL migration compatibility across Windows checkout vs WSL checkout line endings;
  • plugin cache path sanity across Windows and WSL path forms;
  • computer-use availability in the selected runtime mode.

If any check is risky, the prompt should offer a backup/checkpoint/handoff before update and should show target component versions plus expected environment impact.

zhyuzhyu · 2 months ago

Adding another user-facing perspective here because this issue matches a common Desktop update pain point.

The current update flow feels like a black box: when Codex prompts for an update, users cannot tell what will change before accepting it. For a tool that can affect local code, shell execution, plugins, approvals, sandbox behavior, and long-running sessions, that makes the update decision unnecessarily blind.

A practical UX improvement would be either:

  1. Before update: show a comparison and confirmation dialog that summarizes what changed between the current version and the target version, then let the user decide whether to upgrade now.
  2. After update: show a concise update announcement or release note dialog that explains the important changes, similar to the update announcement pattern used by apps like WeChat.

The pre-update option would be better for risk control, especially when users are in the middle of active work. The post-update announcement would still be a meaningful improvement over the current opaque flow.

The key request is that the update UI should make the change content visible in-product, not require users to search GitHub releases, changelogs, issues, or inspect the installed package to understand what was upgraded.