[Windows Desktop] Computer Use rejects Microsoft-signed Word with "executable has multiple signatures"

What version of the Codex App are you using (From “About Codex” dialog)?

Windows package OpenAI.Codex 26.908.9136.0 x64, verified from the installed package and running executable path.
Bundled @oai/sky 0.6.32; Computer Use skill version 26.908.70816.

The production update feed reported the same installed version on 2026-09-16. Package status: Ok.

What subscription do you have?

Not included in this sanitized report.

What platform is your computer?

Native Windows, x64.

What issue are you seeing?

Official Computer Use can enumerate applications/windows, but launching Microsoft Word immediately returns:

executable has multiple signatures

Word does not open, and no test document is created. This persists after a full Windows host reboot, a fresh Node runtime, and a Word update from 16.0.20326.20132 to 16.0.20326.20144.

Both Word versions return Valid from Windows Get-AuthenticodeSignature, with Microsoft Corporation as signer. On version 20132, the primary signature contains one nested Authenticode signature; both signer subjects identify Microsoft Corporation, and both SignedCms.CheckSignature(true) checks pass. Those CMS checks are not separate complete-file/trust-chain checks. The nested structure was not reanalyzed on version 20144.

What steps can reproduce the bug?

1. On the affected Windows desktop installation, initialize the official Computer Use runtime and import @oai/sky according to its bundled skill.
2. Confirm Word appears in list_apps as Microsoft.Office.WINWORD.EXE.15. In the rebooted test baseline, Word was not running and had no windows.
3. Request the official launch:

   await sky.launch_app({
     app: "C:\\Program Files\\Microsoft Office\\root\\Office16\\WINWORD.EXE"
   });
   

4. Observe the immediate native error above, before any Word window or document appears.

The original isolated test invokes this official call through a small lifecycle wrapper. A prior launch using the actual AUMID returned the same error. After reboot, exactly one executable-path launch was attempted; it failed at 09:45:31 China time on 2026-09-16.

No manual approval was displayed during that failed attempt. Since launch failed, this does not establish a complete no-approval workflow. Saving, closing and reopening were not reached. No customer document is needed to reproduce this.

What is the expected behavior?

Computer Use should identify a legitimately Microsoft-signed Word executable while preserving configured application permissions and signature validation, then launch it if allowed. If the signature combination is unsupported, please provide an actionable diagnostic and a supported fix.

Does this native identity component support nested Authenticode signatures from the same publisher? Is there a supported component update or diagnostic step for this rejection?

Additional information

Native component evidence

• codex-computer-use.exe: 1,549,616 bytes.
• SHA256: 284676B863362FF4048069FBED9FD403314B22755D09ED6186FAAF8E1ED254B8.
• The installed resource and active runtime copies are byte-identical.
• The error literal occurs at byte offset 1,259,269, near the compiled source marker src/shell/app_identity/native.rs. No implementation source or call stack was obtained; this localizes the error but does not prove its exact algorithmic cause.

Word hashes

• 16.0.20326.20132: 0260184A0F49583C75F56437C1FEA3CFE3CC1C8CF4054E6CD817C8484AA9B70B.
• 16.0.20326.20144: D6C906171DC2B6C2FE55D1EECF095E077A320646D73DF32C81C6281C21D404E6.

Configuration context

Before this rejection, we found that the UI retained an older always_allowed_app_ids entry while current effective configuration had empty aumids/exes. An owner-authorized narrow migration added Word-specific entries in the current schema. Official config/read now recognizes the Word AUMID allow and one executable rule; default application access remains unset. This does not prove runtime identity matching because launch is stopped by the signature error. The old UI map was retained, so strict unknown-field validation of the entire file is not claimed to pass.

Update check and scope

The installed app's production update feed returned buildVersion: 26.908.9136.0, packageIdentity: OpenAI.Codex, and storeProductId: 9PLM9XGG6VKS, matching the installed package. This observation is time- and channel-specific.

No signature stripping, binary patch, default-all allowance, alternate-tool launch, downgrade, or experimental-channel switch was attempted. Credentials, customer files, private chats and full account configuration are excluded.

An exact-error search of this repository did not find a matching issue before submission.

Start with src/shell/app_identity/native.rs and reproduce the official sky.launch_app call for the reported Word executable on Windows. Compare the native signature handling with the nested Authenticode evidence and determine whether the rejection is expected. Done means a supported Microsoft-signed Word launch, or an actionable diagnostic and documented supported fix that preserves application permissions and signature validation.