Windows: elevated DISM Get-CurrentEdition returns Error 5 in a Codex-origin launch context

Codex App version

Installed MSIX package: OpenAI.Codex version 26.903.9818.0.
Bundled owl-app.ini reports AppVersion=26.903.71938.
These values were read from local installation metadata, not the About dialog.

Subscription

Not included in this technical reproduction.

Platform

Windows 11 Enterprise LTSC 2024, EnterpriseS, x64, build 26100.9445, zh-CN.
PowerShell 7.6.5, x64, installed outside the MSIX package.

Observed issue

The same read-only Windows edition query produces different results depending on how the administrator process is started:

DISM.exe /Online /Get-CurrentEdition /English

The difference was reproduced in three separate rounds. This is a request to help identify the launch-context difference; it does not establish that Codex itself, MSIX, or a security product is the cause.

Reproduction outline

1. In a local Codex desktop task, start a 64-bit PowerShell process using normal Windows UAC elevation (Start-Process -Verb RunAs) and record its administrator status.
2. In that process, run the fixed read-only DISM command above and capture the exit code, stdout, and a separate DISM log.
3. Run the identical query using a temporary native Windows Scheduled Task, with the same interactive user, RunLevel Highest, and the same PowerShell executable. No SYSTEM account is used.
4. Allow the task to finish naturally, inspect the result, and unregister that specific temporary task.
5. Compare the two results. On this machine the original launch path still fails after the scheduled query succeeds.

Successful output:

Deployment Image Servicing and Management tool
Version: 10.0.26100.8972

Image Version: 10.0.26100.9445

Current edition is:

Current Edition : EnterpriseS
The operation completed successfully.

Additional evidence and limits

• A ProcMon trace located the failure at DismHost attempting to open HKLM\SOFTWARE with read/write access.
• In read-only native registry handle tests from the failing administrator context, explicit SetValue, read/write, WRITE_DAC, and WRITE_OWNER requests against the SOFTWARE root return 5. QueryValue, ReadKey, and CreateSubkey handle requests succeed. Equivalent handle requests against SOFTWARE\Microsoft and the SYSTEM root succeed. No registry values are written by these tests.
• Opening SOFTWARE with MAXIMUM_ALLOWED succeeds, and querying the resulting handle reports granted access 0x000F003F. AccessCheck against the retrieved descriptor also predicts the explicitly requested rights are allowed. This makes a blanket ACL reset unjustified.
• The failing and successful administrator probes are 64-bit, report full administrator elevation, and are not AppContainer processes. Traditional token virtualization is disabled in those administrator probes. Their package identity queries return no package identity.
• A separate read-only inspection of the current non-elevated tool process, Codex process, packaged application ancestor, and Explorer found TokenIsSandboxed=0 and TokenIsAppSilo=0. Only the application ancestor reported an MSIX package identity. This does not prove that all inherited runtime effects are absent.
• A controlled DesktopAppPolicy=1 launch test did not change the DISM failure. No claim that MSIX is the proven cause is made.
• The latest parent/probe process environments contained no __COMPAT_LAYER; removing the absent variable did not change the failure. An older trace showed DetectorsAppHealth on DISM, but not DismHost. Its causal relevance is unknown.
• One earlier TokenHasRestrictions probe field was withdrawn because its decoder did not check the returned length. No conclusion relies on the withdrawn value.
• Third-party Lenovo security components and a BAPIDRV driver with Company metadata 360.cn are present. The BAPIDRV signature publisher is Microsoft Windows Hardware Compatibility Publisher. No evidence identifies either component as the cause; this is not a clean-boot or security-product-isolation result.
• Windows cumulative update installation is separately verified, and SFC completed with no integrity violations. Native DISM can identify the edition successfully.
• No registry permissions, Windows edition identifiers, CBS package states, Codex security settings, or global compatibility settings were modified for this launch-context investigation.

Expected behavior / question

The read-only query should be usable from the supported administrator launch path. Is there a documented Codex/Windows launch-context behavior that explains this exact registry access difference, or another targeted diagnostic that can identify it without changing system ACLs or disabling protection?

The native scheduled query is currently a verified workaround. The original Error 5 remains unresolved and is not being reported as fixed.

This report contains no account identifiers, local user paths, machine identifiers, financial application data, or full diagnostic archives.

Begin with the Codex desktop task reproduction using Start-Process -Verb RunAs, the fixed DISM command, and separate stdout and log capture. Compare that administrator launch with the temporary highest-run-level Scheduled Task, then inspect the mentioned ProcMon DismHost trace and registry handle results. Done means identifying a documented launch-context difference or a targeted diagnostic that explains Error 5 without changing ACLs or disabling protection.