Windows codex exec reaches restricted-token sandbox despite explicit windows.sandbox="elevated" selector

Environment

• Native Windows
• codex-cli 0.149.0
• Standalone executable invoked by absolute path
• Elevated Windows sandbox provisioned successfully
• No managed/system configuration forcing unelevated

Summary

The explicit CLI override:

--config windows.sandbox="elevated"

works correctly with the no-model codex sandbox helper, including when using the exact permission profile supplied to my automation.

The helper runs under a dedicated sandbox identity and exits successfully.

The equivalent codex exec invocation fails before model work with:

windows unelevated restricted-token sandbox cannot enforce split filesystem read restrictions directly; refusing to run unsandboxed

This error appears to come from the RestrictedToken path even though windows.sandbox="elevated" was explicitly supplied.

Sanitized exec ordering

codex.exe
--config windows.sandbox="elevated"
--ask-for-approval never
exec
--skip-git-repo-check
--cd <managed-workspace>
--ignore-user-config
--ignore-rules
--strict-config
--ephemeral
--json
...

There is exactly one Windows sandbox selector. There is no later unelevated override or legacy Windows sandbox feature selector.

The executable is invoked using a subprocess argument array with shell=false.

Control probes

Probe A — baseline elevated helper

codex sandbox
--config windows.sandbox="elevated"
--
whoami.exe

Result:

exit code: 0
sandbox identity differs from host: yes
restricted-token/fallback marker: none

Probe B — elevated helper with the automation permission profile

The probe adds the same effective policy used by exec:

default_permissions="priya-workspace-only"

permissions.priya-workspace-only.extends=":workspace"

permissions.priya-workspace-only.filesystem={
  ":root"="deny",
  ":minimal"="read",
  ":tmpdir"="deny",
  ":slash_tmp"="deny"
}

permissions.priya-workspace-only.network.enabled=false

Result:

exit code: 0
dedicated sandbox identity observed: yes
restricted-token/fallback marker: none

This demonstrates that the permission profile itself works under the explicitly selected elevated sandbox.

Strict-config note

codex-cli 0.149.0 reports that --strict-config is not supported by the codex sandbox helper, so it could not be included in the no-model helper probe. It remains enabled and mandatory on the failing codex exec invocation.

Other findings

• --ignore-user-config does not remove explicit command-line --config overrides in the tagged 0.149 source.
• No managed or system configuration forcing unelevated was found.
• No conflicting sandbox selector appears later in the command.
• Elevated sandbox provisioning is healthy.
• Failure occurs during session/environment preparation, before model work.
• Unsandboxed fallback is correctly refused.

Expected behavior

An explicitly selected and successfully provisioned elevated Windows sandbox should remain selected throughout codex exec session creation.

If another configuration layer overrides that selector, codex exec should expose which layer and effective value caused the change.

Actual behavior

The same explicit selector and permission profile:

• use the elevated implementation successfully through codex sandbox;
• reach the unelevated restricted-token path through codex exec.

Diagnostic questions

1. Is there a supported no-model way to inspect the effective Windows sandbox implementation selected by codex exec immediately before thread/session creation?
2. Is this a known configuration-propagation or sandbox-selection defect in codex-cli 0.149.0?
3. If fixed, which release contains the correction?
4. Can codex exec log the effective WindowsSandboxLevel and the configuration layer that selected it without starting a model request?

Possibly related issue

#28278 may be adjacent because it concerns Windows codex exec, sandbox setup, and runtime entry-point resolution.

It does not appear to describe the same failure:

• #28278 uses CLI 0.137.0 and reports helper discovery/launch error 1223.
• This report uses CLI 0.149.0, an absolute standalone executable, and a helper that successfully starts elevated in no-model probes.
• The discrepancy here is the effective sandbox implementation selected during exec.

Official context: OpenAI documents elevated as the preferred Windows sandbox implementation and unelevated as the fallback. Windows sandbox documentation