[Windows Desktop] code-mode sandbox omits implicit workspace root from ACL setup

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

26.818.5345.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On Codex Desktop for Windows, a local project can be correctly registered as a runtime workspace root and writable under the managed permission profile, but the project's ACL is never provisioned for the Windows sandbox identities.

Sandboxed commands then fail before the requested process starts. One observed error was:

CreateProcessWithLogonW failed: 267

The setup helper itself reports success:

setup refresh: processed 2 write roots (read roots delegated); errors=[]

However, it never logs an ACL check, grant, missing-root warning, or failure for the actual project directory.

I reproduced the same behavior with two independently registered local projects. Visualization and temporary directories are provisioned normally, while both project roots are omitted.

What steps can reproduce the bug?

1. On Windows, create or select a normal local project under a directory such as:

   C:\Users\<user>\work\project-a
   

   The project and its parent should not already have Codex sandbox ACL entries.

2. Register/open the directory as a local project in Codex Desktop.

3. Use the managed workspace-write permission mode. In the affected app build, the internal code_mode_buffered_exec feature is enabled.

4. Start a task and ask Codex to run a simple shell command from the project, such as Get-Location.

5. Observe that the sandboxed process may fail to start with:

   CreateProcessWithLogonW failed: 267
   

6. Inspect the recorded turn context. In my reproduction, the relevant state was equivalent to:

   cwd:
     C:\Users\<user>\work\project-a
   
   workspace_roots:
     - C:\Users\<user>\work\project-a
     - C:\Users\<user>\.codex\visualizations\<date>\<thread>
   
   managed permission profile write entries:
     - C:\Users\<user>\work\project-a
     - C:\Users\<user>\.codex\visualizations\<date>\<thread>
     - temporary-directory roots
   
   legacy sandbox_policy.writable_roots:
     - C:\Users\<user>\.codex\visualizations\<date>\<thread>
   

   Thus, the project is present in workspace_roots and the managed permission profile, but absent from the legacy writable-root list because it is treated as the implicit workspace root.

7. Inspect <CODEX_HOME>\cap_sid. The affected project is absent from both:

   workspace_by_cwd
   writable_root_by_path
   

   The visualization and temporary roots have capability entries.

8. Inspect <CODEX_HOME>\.sandbox\sandbox.<date>.log. The helper grants or refreshes the visualization ACL and reports no setup errors, but never mentions the project directory.

9. Inspect the project ACL. It has no inherited or explicit entry for the Codex sandbox group or a per-root capability SID.

The issue occurred independently for two local projects. Session IDs and raw logs are omitted from this public report because they contain unrelated local paths and task history, but sanitized excerpts or the original logs can be provided privately if maintainers need them.

What is the expected behavior?

Every effective runtime workspace root that is writable under the managed permission profile should be included in the Windows sandbox ACL setup plan.

The setup helper should receive the project root in write_roots, create or retrieve its per-root capability SID, apply the required sandbox-group and capability-SID ACLs, and report an actionable error if any step fails.

The legacy representation may omit the workspace from sandbox_policy.writable_roots because the workspace is implicit, but consumers must materialize runtimeWorkspaceRoots before preparing Windows ACLs.

Additional information

The sandbox installation itself appears healthy:

• The offline and online sandbox accounts exist and are members of the expected sandbox group.
• The setup marker is current.
• codex doctor --json considers sandbox provisioning complete.
• The setup helper runs on each attempted command and returns errors=[].
• The packaged and locally cached Codex/setup-helper binaries are byte-identical.
• The affected directories are ordinary local NTFS directories with ACL inheritance enabled.
• The problem is not limited to one repository or its contents.

The current Windows setup helper iterates payload.write_roots, creates or retrieves a per-root capability SID, checks the ACL, and logs any grant or failure:

https://github.com/openai/codex/blob/main/codex-rs/windows-sandbox-rs/src/bin/setup_main/win.rs

Because the affected projects have no capability-ledger entry and are never mentioned in the sandbox log, they appear not to reach that loop at all.

Root-cause hypothesis: the Codex Desktop code-mode/kernel startup path constructs the sandbox helper payload from the legacy sandbox_policy.writable_roots list, which contains only additional roots, without adding the effective runtime workspace roots back into the list.

This resembles the failure class addressed by:

https://github.com/openai/codex/commit/986c60467b96ca13850217f6e5adadef6ba70ab3

That change explicitly passes effective workspace roots through Windows command-execution paths so :workspace_roots can be materialized. The current upstream source also contains a regression test named:

legacy_session_capability_roots_use_runtime_workspace_roots_for_workspace_root

The installed Desktop code-mode path may be a missed or reintroduced call site.

Manually granting the sandbox group access to the project and traversal access to its parent makes commands run, but this is only a workaround and does not restore the intended per-root capability-SID provisioning.

Start with codex-rs/windows-sandbox-rs/src/bin/setup_main/win.rs and trace the Windows code-mode/kernel startup path that builds the helper payload. Compare that path with the regression test legacy_session_capability_roots_use_runtime_workspace_roots_for_workspace_root and the referenced commit. Done means effective runtime workspace roots reach write_roots, receive capability entries and ACL setup, and the relevant tests pass.