Windows Codex Desktop 26.908.40834: write operations hang; clean workspace never launches requested write command

Environment

• Codex Desktop version: 26.908.40834
• Platform: Windows
• Subscription: ChatGPT Plus
• Model: GPT-5.6 Sol
• Windows user: 2025-04-10-D01\COSH
• Current user SID: S-1-5-21-2638354131-1635556175-1629256366-1001
• System was fully rebooted during troubleshooting.
• Usage limits were not exhausted (about 98% of the current 5-hour allowance remained during testing).

Summary

Codex Desktop can perform some read-only operations, but write-oriented operations hang indefinitely.

Controlled testing indicates two separate failure modes:

1. An existing project workspace fails during sandbox ACL setup with SetNamedSecurityInfoW failed: 5.
2. A newly created clean workspace has correct ownership and successful sandbox ACL setup (errors=[]), but an explicitly requested PowerShell write command is never launched and does not appear in the sandbox log.

The second failure reproduces independently of the original repository, Git, project configuration, custom agents, or workspace ACL ownership.

Failure mode 1 — Existing project: sandbox ACL setup fails

Existing project:

D:\eevision_xe10\evmesh

Sandbox log reports:

granting write ACE to D:\eevision_xe10\evmesh for sandbox group and capability SID
write ACE grant failed on D:\eevision_xe10\evmesh: SetNamedSecurityInfoW failed: 5

deny ACE failed on D:\eevision_xe10\evmesh\.git:
SetNamedSecurityInfoW failed for D:\eevision_xe10\evmesh\.git: 5

setup refresh completed with errors
setup error: setup refresh had errors

ACL inspection shows normal inherited permissions including Authenticated Users:(M), but the workspace and .git owner SID differ from the currently logged-in Windows user's SID:

Workspace owner:
S-1-5-21-2283855486-1997267379-3259020087-1001

Current user:
S-1-5-21-2638354131-1635556175-1629256366-1001

Normal file modification is possible through inherited permissions, but Codex fails when attempting to modify the security descriptor.

Failure mode 2 — Clean workspace: ACL setup succeeds, but write command is never launched

To isolate the issue, I created a completely new directory and opened it as a new Codex project:

D:\codex_test

Owner is the current user:

(Get-Acl "D:\codex_test").Owner
2025-04-10-D01\COSH

ACL after Codex initialization includes:

2025-04-10-D01\CodexSandboxUsers:(OI)(CI)(M)
S-1-5-21-3298927432-701962161-1885063525-1065416621:(OI)(CI)(M)

The sandbox log confirms successful workspace-write ACL provisioning:

granting write ACE to D:\codex_test for sandbox group and capability SID
setup refresh: processed 3 write roots (read roots delegated); errors=[]
setup binary completed
read-acl-only mode: applying read ACLs
read ACL run completed
helper launch resolution: using copied command-runner path ...

Reproduction test

In a new session using D:\codex_test, I explicitly instructed Codex to execute only:

Set-Content -LiteralPath '.\code_test2.txt' -Value 'hello'

and not to use any alternative method.

Codex entered the processing/running state but did not complete the operation.

Most importantly, Set-Content never appears anywhere in the sandbox log.

The same log contains other commands such as Get-Content and Get-Item, so command logging is active. The explicitly requested write command appears never to reach the sandbox execution layer.

This suggests the write request may be hanging or being lost before reaching codex.exe / codex-command-runner / PowerShell.

Additional controlled tests

Tests performed include:

• Existing Visual Studio C++ repository
• New Codex sessions
• Completely new Codex project
• Clean directory unrelated to the repository
• Full Windows reboot
• Read-only operations
• File creation/write operations

Observed pattern:

• Some read-only operations succeed.
• Write/create operations hang.
• In the original repository, sandbox ACL setup itself fails.
• In the clean workspace, ACL setup succeeds but the requested write command may never be launched.

The clean-workspace failure therefore does not appear to be caused solely by Git, .git, repository contents, project instructions, custom agents, Visual Studio, exhausted usage limits, the original conversation/session, or ordinary NTFS write permission.

Global Codex configuration

%USERPROFILE%\.codex\config.toml contains only:

model = "gpt-5.6-sol"
model_reasoning_effort = "xhigh"

There are no custom approval_policy, sandbox_mode, or Windows sandbox settings in the global configuration.

Other sandbox-log observation

The command runner repeatedly logs:

hide users: failed to hide current user profile dir (C:\Users\Default):
SetFileAttributesW failed for C:\Users\Default: 5 (Access is denied.)

This also occurs during runs where workspace ACL setup otherwise reports errors=[]. Permissions/ownership of C:\Users\Default have not been modified during troubleshooting.

Expected behavior

With a clean workspace and successful sandbox provisioning, a simple command such as:

Set-Content -LiteralPath '.\code_test2.txt' -Value 'hello'

should be dispatched to the sandbox command runner and create the file.

Actual behavior

Codex remains in a running/processing state, but the requested write command is never observed in the sandbox log and the file is not created.

Possibly related issues

This may be related to other Windows sandbox regressions reported against Codex Desktop 26.908.40834, including #45152 and #45153 (SetNamedSecurityInfoW / sandbox initialization failures).

However, the clean-workspace reproduction appears different from a pure ACL failure because the workspace owner is correct, CodexSandboxUsers has Modify permission, sandbox write-ACE provisioning reports errors=[], and the requested write command itself never appears in the sandbox log.

This may indicate an additional tool-dispatch / turn-lifecycle / command-submission problem above the Windows sandbox execution layer.

I can provide the complete sandbox.2026-09-15.log if needed. It contains both the SetNamedSecurityInfoW failed: 5 failures against the existing repository and successful errors=[] provisioning for the clean workspace.

Start with the clean-workspace reproduction in D:\codex_test and trace the requested PowerShell command through codex.exe, codex-command-runner, and the sandbox log. Compare the successful ACL setup with the missing Set-Content entry, then examine the existing-workspace SetNamedSecurityInfoW failures. Done means the write command is dispatched, appears in the log, and creates code_test2.txt without regressing sandbox setup.