Windows Codex App installer/update failures need clearer recovery and diagnostics

What issue are you seeing?

The Windows Codex desktop app installation/update path feels fragile and hard to recover when it fails. Users can end up in states where the app fails to install, fails after an update, leaves duplicated/opaque runtime artifacts, or starts with broken app-server/Desktop state, but the product does not provide a clear recovery path or actionable diagnostics.

This is not one single error-code report. It is a Windows app reliability/diagnostics issue: when install/update/first-launch fails, the user often has to search GitHub issues, manually inspect local folders, reinstall, or guess which runtime state needs cleanup.

Observed related symptoms already reported across issues include fresh-install app-server unavailable, interrupted update causing startup failure, duplicated executables/runtime paths, sandbox setup failures after updates, and unclear uninstall/cleanup behavior.

What steps can reproduce the bug?

A broad version of the failure path is:

1. On Windows, install Codex App or let the app auto-update.
2. Hit an installation/update/first-launch failure or broken post-update state.
3. Try to recover using only the app UI and normal Windows uninstall/reinstall flows.
4. The user does not get enough information to know whether the issue is installer state, duplicated binaries, app-server state, sandbox setup, protocol handler, stale local data, or update corruption.

Examples of related existing reports that point to the same reliability area:

• #25671: Windows app fails on fresh install - Electron app not found / app-server unavailable
• #30543: crashes after interrupted/unstable automatic update; manual latest install fixes it
• #27230: duplicated executables, opaque runtime paths, sensitive local state without cleanup/uninstall controls
• #29771: update churn reintroduces sandbox setup failures
• #13993: request for standalone Windows installer

What is the expected behavior?

The Windows Codex App install/update flow should provide a robust recovery path and clear diagnostics:

• A reliable installer/update flow that can repair partial or interrupted installs.
• A visible diagnostic bundle or log export button for install/update/app-server startup failures.
• Clear user-facing error messages that distinguish installer failure, update corruption, app-server failure, sandbox setup failure, protocol handler failure, and auth/session state problems.
• A first-party repair/reset option that can clean app runtime artifacts without deleting user credentials or thread state unexpectedly.
• A documented safe uninstall/reinstall/repair path for Windows users.
• Ideally, a standalone installer option for environments where Microsoft Store/MSIX/App Installer behavior is unreliable or restricted.

Additional information

Windows users should not need to reverse-engineer local runtime paths or manually clean partial app state just to recover from failed install/update states. Even if every underlying failure has a separate root cause, the product needs a better Windows-level installer/update recovery and diagnostics experience.