Desktop runtime release mismatch: authenticated bootstrap selects 26.909.22227 while public LATEST advertises 26.909.61513

Desktop selects an older primary runtime than the public LATEST feed; external preflight and Desktop repeatedly replace each other's bundle

Environment

• Windows x64, Microsoft Store package OpenAI.Codex 26.911.7940.0
• Internal application version: 26.911.61220; build flavor: prod
• Investigation date: 2026-09-17

Verified observations

1. The official public manifest at https://persistent.oaistatic.com/codex-primary-runtime/latest/win32-x64/LATEST.json advertises bundle 26.909.61513.
2. Desktop startup logs select source=statsig-layer and latest.bundleVersion=26.909.22227.
3. Independent authenticated POST requests to the same official bootstrap endpoint used by the application, https://chatgpt.com/backend-api/wham/statsig/bootstrap, returned latest=26.909.22227. The second request used internal app version 26.911.61220, prod, Windows, and electron. It completed at 2026-09-17T17:54:25+08:00. This is an independent read of the endpoint, not a capture of Desktop's own network request; the app session identifier was newly generated for the probe.
4. Layer 2096615506, codex-primary-runtime, returned latest-alpha=26.909.11809. Public bundle 26.909.61513 was absent from its versions mapping.
5. Desktop installed 26.909.22227 successfully after a separate local startup preflight installed 26.909.61513. The preflight used the public LATEST feed. On the next launch the preflight installed 26.909.61513 again, causing another Desktop installation.
6. Removing that external updater from the startup chain stopped the loop. The user confirmed a subsequent restart did not reinstall. Desktop diagnostics reported installed=true and problemCount=0 for 26.909.22227.

Scope and limitations

The repeated install loop involved a custom external startup updater; it has not been established on an unmodified installation. The unresolved product question is the mismatch between two official version-selection sources and the supported way to use the public latest bundle. No compatibility failure of 26.909.61513 was established. A deliberate rollout, rollback, or stale server configuration has not been confirmed.

Questions for maintainers

1. Is this public-manifest versus authenticated-bootstrap mismatch intentional? Which source is authoritative for production Desktop installations?
2. Is 26.909.61513 held back for this app build or account cohort, or is the bootstrap layer stale?
3. Is there a supported way to refresh or select 26.909.61513 while preventing automatic replacement by 26.909.22227?
4. For external preflight installation, is there a documented authoritative manifest or supported installer interface that follows Desktop release selection?

No credentials, account identifiers, stable device identifiers, private paths, or session transcripts are included.

Start by comparing the public LATEST.json manifest with the authenticated /backend-api/wham/statsig/bootstrap response for the documented Windows production context. Trace how Desktop selects and installs the primary runtime, then establish which source is authoritative and what supported behavior prevents the two bundles from replacing each other.