Windows elevated sandbox exits with code 1 before child identity probe

Privacy: paths, user and account names, SIDs, authentication data, and raw CLI output have been removed.

Summary

On a Windows 10 22H2 x64 test machine, the native Codex elevated sandbox exits with code 1 before a minimal PowerShell child can emit an identity fingerprint and completion marker. The same behavior was observed with Codex CLI 0.149.1 and 0.150.1.

The Codex process starts and both redirected streams reach EOF, but no child identity marker is observed. Sanitized diagnostics contain no Win32 error code and do not match the known setup, logon, callback, path-alias, or helper failure categories. The effective sandbox therefore remains Unknown.

Official documentation says native Windows sandbox setup failures commonly involve UAC, local user/group creation, firewall changes, required logon rights, or enterprise policy. The evidence below confirms some setup artifacts but does not identify which setup stage fails. Reference: OpenAI Windows sandbox documentation.

Environment

• OS: Windows 10 22H2, 64-bit
• Invocation user: standard, non-administrator Windows process
• Authentication: ChatGPT login status succeeds in a dedicated CODEX_HOME
• Credential storage: cli_auth_credentials_store = "keyring"
• Login policy: forced_login_method = "chatgpt"
• Sandbox config: [windows] sandbox = "elevated"
• Plaintext auth.json: absent
• Parent environment: cleared, then populated from an explicit 12-name allowlist
• API keys, access tokens, endpoint overrides, and provider overrides: not inherited
• Working directory: application-owned, empty, non-Git temporary directory
• Setup artifacts observed without recording their names or SIDs:
  • sandbox local users: 2
  • sandbox local groups: 1
  • related firewall rules: present
  • enabled outbound blocking rules: present

Tested CLI builds

CLI	Native SHA-256	Setup helper SHA-256	Result
0.149.1	a395030b56b126f608f2403036dddb654a9c063213e9c2b5f85d954cf490ebe6	cff8f8861d0bb0dba601f5d4e74d8eeb578a6b9a5956a6a83c818dafc7d4894a	AbnormalExit/1, identity not observed
0.150.1	cbd657ddfe151d1a6ebad660beffdbd3265dc5aff4b3a6095124d3e2f0156f2f	9a81b03a86c3a597d3df1e9d14e8a9bb25d926d0266d7ddd5cefb0307a9f9b1b	AbnormalExit/1, identity not observed

Both versions came from the official npm package layout. The launcher, native executable, platform manifest, and codex-windows-sandbox-setup.exe versions matched within each installation.

Reproduction shape

The application invokes the verified native executable with arguments equivalent to:

codex -c windows.sandbox="elevated" sandbox -- <system-powershell> -NoLogo -NoProfile -NonInteractive -EncodedCommand <fixture>

<fixture> is a deterministic script that:

1. obtains the current child Windows SID in memory,
2. hashes it with SHA-256,
3. emits only the first 16 lowercase hexadecimal characters as HDF_IDENTITY_FINGERPRINT=<fingerprint>,
4. emits HDF_IDENTITY_PROBE_COMPLETED=TRUE, and
5. does not read or modify user documents, credentials, registry values, network resources, or sandbox secrets.

The application then waits for process exit and stdout/stderr EOF, validates the two markers, compares the fingerprint only with pre-hashed sandbox account fingerprints, and deletes the exact owned temporary directory.

The installed CLI reports the supported syntax as:

codex sandbox [OPTIONS] [COMMAND]...

Expected result

• Codex starts the child in the configured elevated Windows sandbox.
• The child exits normally with code 0.
• stdout and stderr reach EOF.
• Exactly one identity fingerprint and one completion marker are observed.
• The fingerprint matches one of the sandbox local accounts and differs from the parent identity.

Actual result

Codex CLI 0.149.1

• Exit: AbnormalExit/1
• stdout/stderr EOF: completed
• Application classifications: ProcessFailure, IdentityNotObserved
• Sanitized runtime classification: Unknown
• Win32/OS error code: none observed
• Sandbox account fingerprints available to the parent: 2
• Identity and completion markers: not observed
• Owned temporary files after cleanup: 0

Codex CLI 0.150.1

• Exit: AbnormalExit/1
• stdout/stderr EOF: completed
• Application classifications: ProcessFailure, IdentityNotObserved
• Sanitized runtime classification: Unknown
• Win32/OS error code: none observed
• Sandbox account fingerprints available to the parent: 2
• Identity and completion markers: not observed
• Owned temporary files after cleanup: 0

Stable boundary evidence for the 0.150.1 run:

• executable path fingerprint: babdcb7fc78eb357
• dedicated home fingerprint: 8999ae60a83c19ac
• environment-name-set fingerprint: 51a92e63602993a3
• execution-boundary fingerprint: b87303287871ed38

No sandbox.log was available in the application-specific documented candidate locations during the earlier diagnosis. Raw stdout, stderr, and login logs were intentionally not retained.

Additional observations

• codex login status exits normally with code 0 and confirms ChatGPT authentication in the same executable and dedicated-home boundary.
• The configuration hash and authentication policy remained unchanged before and after both probes.
• A plaintext auth.json was not created.
• Upgrading from 0.149.1 to 0.150.1 changed the native and helper binaries but did not change the failure behavior.
• The application did not retry the probe, rerun sandbox setup, switch to the unelevated sandbox, or modify users, groups, firewall rules, logon rights, ACLs, or authentication.

Questions for maintainers

1. Which diagnostic flag or supported log should capture the first failed stage when codex sandbox exits with code 1 but emits no recognizable error or OS code?
2. Is there a supported read-only method to verify the exact sandbox-user logon right expected by these CLI versions?
3. Can the helper report or provisioning state be inspected without rerunning setup or opening .sandbox-secrets?
4. Is this identity-marker-free AbnormalExit/1 behavior a known issue on Windows 10 22H2 for 0.149.1 or 0.150.1?

Start with the codex sandbox -- <command> entry point and reproduce the Windows elevated run using the deterministic PowerShell fixture described here. Investigate the supported diagnostic flag or documented sandbox.log locations to identify the first failed setup stage without changing provisioning. Done means the failure reports a recognizable stage or error, or the behavior is confirmed as a known issue for the listed Windows and CLI versions.