[Windows] workspace-write allows repo-root writes but denies child directories; elevated sandbox fails with error 1385

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

codex-cli 0.144.1

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On native Windows, the Codex App workspace-write sandbox behaves
inconsistently across a single repository.

With:

approval_policy = "never"
sandbox_mode = "workspace-write"

[windows]
sandbox = "unelevated"

Codex can create and delete files directly in the repository root, but all
ordinary writes fail with Access denied in existing child directories,
including:

scripts
workflow-docs
work/runtime

The native apply_patch helper fails in the same child directories.

Equivalent create, overwrite, rename, and delete operations succeed from
ordinary PowerShell outside Codex under the same Windows user.

With:

[windows]
sandbox = "elevated"

the situation becomes worse: all command execution fails before the requested
command starts, with:

CreateProcessWithLogonW failed: 1385

The problem is not affected by approval_policy = "never" versus
"on-request".

The visible token under unelevated reports:

normal Windows user at medium integrity;
Authenticated Users enabled;
no CodexSandboxUsers membership;
no visible restricted or deny-only SIDs.

Repository files remain writable from normal PowerShell.


## What steps can reproduce the bug?

```markdown
Feedback ID:

```text
019f5855-f013-78b0-beaf-13e4ef741b68

### What steps can reproduce the bug?

Feedback ID: 019f5855-f013-78b0-beaf-13e4ef741b68

### What is the expected behavior?


## Expected behavior

```markdown
Under `sandbox_mode = "workspace-write"`, Codex should be able to create,
overwrite, rename, delete, and patch files in all normal child directories
beneath the declared writable repository root.

Filesystem behavior should not differ between the repository root and its
ordinary existing subdirectories.

When `windows.sandbox = "elevated"` is selected, the sandbox should either
initialize successfully or return a clear setup error. It should not leave the
App unable to start any command with `CreateProcessWithLogonW failed: 1385`.

### Additional information

Related existing issues:

#14585 — Windows sandbox path-sensitive failure where repository-root writes
work but child-directory apply_patch operations fail.
#16780 — elevated Windows sandbox fails before process startup with
CreateProcessWithLogonW failed: 1385.
#27785 — workspace-internal shell writes fail without a useful escalation or
early-stop path.

Additional diagnostics:

Normal PowerShell has working write, rename, and delete access in all affected
directories.
config.toml parses successfully.
Agent TOML files contain no sandbox, filesystem, permission, or writable-root
configuration.
Plugin icon warnings and plugin-cache files are unrelated to the write
failure.
Manual Allow ACL grants to CodexSandboxUsers did not resolve the problem.
The visible unelevated token does not contain CodexSandboxUsers.
No tracked files were modified by the reproduction tests.
An unresolved Deny SID exists in some Codex-managed ACLs, but it is not
present in the visible whoami /all token, suggesting that an internal child
or impersonation token may differ from the visible shell token.