How can a Windows Store Codex package be mapped to its bundled CLI/app-server version and source commit?

[turun574]

I need an authoritative mapping for this Windows Store Codex package:

PackageFullName:
OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0

Package version:
26.803.10989.0

Bundled executable:
app\resources\codex.exe

Executable size:
293412656 bytes

Executable SHA-256:
592958896CBFFA154709618476FC9C9BF7FE73957E9A4FC12094C5051B6C69B3

Direct execution of the packaged executable with --version could not be
established, so I do not want to infer its CLI version from the Store package
version or select a nearby public release.

Could an OpenAI maintainer clarify:

1. What exact Codex CLI/app-server version is bundled in this package?
2. What exact openai/codex release tag and full commit SHA produced it?
3. Is there an official manifest, API, or deterministic mapping from the
   Windows Store package version to the bundled CLI version and source commit?
4. Is the Store package version independently versioned from the bundled CLI?
5. Is there an official way to obtain the generated TypeScript or JSON Schema
   bundle for this exact packaged version without copying or directly executing
   the WindowsApps binary?

The App Server documentation states that generated schemas are specific to the
Codex version that generated them:
https://learn.chatgpt.com/docs/app-server#message-schema

I am looking for an authoritative mapping, not an inferred or approximate one.

[sylvesterkaczmarek]

From what is publicly exposed today, I don't think there is an authoritative Store-package → CLI tag/SHA mapping you can derive yourself.

The Store version should be treated as the app/package version, not assumed to equal the Codex CLI release number. The documented deterministic route is the binary itself: codex app-server generate-ts or generate-json-schema, whose output is guaranteed to match that Codex version.

So unless OpenAI publishes a manifest for 26.803.10989.0, I don't think the exact release tag/commit can be proven from the Store package number or executable SHA alone. A maintainer-provided mapping would be needed for that.

[hennep01]

Adding another concrete Store-package case to this mapping question. The purpose is bounded synthetic observer validation, for which a public CLI source reference alone is not enough to establish the supported behavior of the packaged binaries.

Package: OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0 (Windows x64).

The three local binary copies were verified byte-identical to their corresponding Microsoft Store package payloads:

Binary	Bytes	SHA256
codex.exe	316853040	BC45017E8239DC150258F69309CED9DF6BBCDF5B8E4F346DECF780AC0999E226
codex-command-runner.exe	8234800	673F263039D9547EFDBC445DCE700BC20549D8AB480FDFA99BCA9DFB040FB0D1
codex-windows-sandbox-setup.exe	15455024	827CBF395D0DA31BE53A1A8A85E98F8BDBCE2C265C4F1E95B4CCAAE61D728370

Static inspection of the packaged codex.exe found embedded version 0.155.0-alpha.9.2 and revision 4607249e430dac1c961df4dc615beae88e33cec8. The public rust-v0.155.0-alpha.9.2 release/tag points to that same commit. However, the public Windows release-asset SHA256 values observed during the earlier analysis differed from these Store-package binary hashes.

That is a provenance gap, not evidence of its cause. I am not claiming tampering, a vulnerability, or a reproduced bug. A prior OpenAI support exchange did not provide an engineering attestation.

Could Codex/Windows engineering clarify:

1. Package/build provenance: Can each of these three exact Store-package hashes be linked to 4607249e430dac1c961df4dc615beae88e33cec8? Are there additional source deltas, and which relevant build/profile/features, toolchain, packaging or signing differences explain the observed difference from the public release assets? Private source code is not requested; a build-specific attestation or mapping is sufficient.

2. Supported diagnostic invocation: For this exact desktop/package build, is there an officially supported, credential-free standalone Windows sandbox diagnostic invocation for bounded synthetic observer validation? If yes, please specify the executable, exact argv and minimum required context, including cwd, environment/home variables and sandbox mode. If none exists, an explicit maintainer confirmation is also useful.

3. Pre-target effects: For that invocation, what config/auth/credential reads, home resolution, file or log writes, initialization/setup, registry/ACL/service/task changes, network access or helper activity can occur before the target launches? Please distinguish unconditional effects from conditional ones and state the relevant conditions.

4. Process/actor chain: Which roles are performed by codex.exe, codex-command-runner.exe, codex-windows-sandbox-setup.exe, any service/helper, the sandbox actor and the target? Which components may participate before or during target launch?

5. Applicability boundary: Please distinguish public CLI release behavior from Microsoft Store desktop/package behavior, and identify which conclusions about a standalone diagnostic do or do not transfer to the desktop/App Server launch path.

I reviewed #46442 and #6065. This comment stays with this thread's package-to-source mapping question and asks for its supported-behavior implications; it does not request a new PowerShell launcher or a trial execution.