Windows Codex App: authenticated SMB/UNC workspaces fail in both sandbox modes

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #35380

Powered by Codex Action

I don’t believe this report should be closed as a duplicate of https://github.com/openai/codex/issues/35380. The similar errors may indicate that both cases are caused by the same underlying bug in the application, but https://github.com/openai/codex/issues/35476 reproduces it in a very different context: a normal authenticated SMB share rather than a \wsl.localhost workspace. It also provides additional diagnostics and demonstrates different behavior in elevated and unelevated sandbox modes. I believe keeping this report open gives the developers an important additional perspective for identifying the root cause and designing a complete fix.

Follow-up: source-level findings, credential isolation, and a possible secure SMB sandbox design

I performed additional controlled testing and reviewed the current public Codex Windows sandbox source with assistance from OpenAI Codex.

The results suggest that this problem consists of at least three layers:

1. the elevated setup helper attempts to apply local ACL-based sandbox identities to remote SMB roots;
2. the elevated command runner does not load the dedicated sandbox user's Windows profile, so credentials stored interactively for that account are not available in the same way;
3. the unelevated restricted-token model may not be compatible with write authorization on a remote server that cannot resolve Codex's locally generated capability SIDs.

The source observations below are investigation leads rather than confirmed root causes. The public main branch may not exactly match the implementation bundled with Codex App 26.721.4979.0.

Verified behavior

The following behavior was reproduced in the affected environment:

• Host PowerShell can access the authenticated SMB share normally.
• DNS resolution succeeds inside the sandbox.
• TCP port 445 is reachable inside the sandbox.
• The mapped network connection is visible.
• Windows Credential Manager contains the SMB credential.
• The unelevated sandbox runs under the same primary Windows user as the host.
• The unelevated sandbox still receives Access denied for the UNC path.
• The elevated sandbox fails during setup refresh before the requested command starts.
• A configured UNC writable root can break an otherwise unrelated command whose requested working directory is local.
• apply_patch can create a file on the share in one path, but subsequently fails to read or update that file with error 5.
• The dedicated CodexSandboxOnline account can access the same SMB share when logged into Windows interactively after the NAS credential has been stored for that account.
• A runner started by Codex as CodexSandboxOnline still cannot access the share.
• During failing sandbox probes, I did not observe corresponding rejected SMB authentication attempts in the NAS log. I only observed the successful folder access from the interactive tests. This suggests that at least some failures may occur locally before a usable SMB authentication attempt reaches the server.

The short hostname and FQDN resolve to the same NAS. The issue does not appear to be caused by DNS or TCP reachability.

1. Elevated setup treats remote writable roots like local ACL-capable roots

The setup helper iterates through every configured write root, checks its ACL, and attempts to grant access to the local Codex sandbox group and generated workspace capability SIDs:

https://github.com/openai/codex/blob/8e271dc02b23d42827875019924be0f5005642b0/codex-rs/windows-sandbox-rs/src/bin/setup_main/win.rs#L830-L909

I could not find an early classification that separates:

• local NTFS paths;
• mapped SMB drives;
• direct UNC paths;
• extended \\?\UNC\... paths;
• remote filesystems that cannot persist or resolve local Windows SIDs.

A separate NAS cannot normally resolve locally generated Codex capability SIDs. Attempting to install those identities into a remote ACL is therefore a plausible explanation for:

SetNamedSecurityInfoW failed: 5

Even if full SMB sandbox enforcement is not currently possible, one unsupported remote root should not cause every local sandbox command to fail during global setup refresh.

A safe implementation should not simply skip enforcement and run the remote path unsandboxed. However, Codex could at least:

• detect remote roots before ACL mutation;
• prevent an unsupported remote root from poisoning unrelated local commands;
• report the exact incompatible root and filesystem type;
• return a specific actionable error instead of helper_unknown_error;
• use a remote-aware enforcement mechanism if authenticated SMB workspaces are intended to be supported.

This is also relevant because the current Codex permissions documentation describes native Windows drive-letter and UNC paths as supported absolute paths.

2. The elevated runner deliberately does not load the sandbox user's profile

The current public source starts the elevated command runner using CreateProcessWithLogonW, but passes dwLogonFlags = 0:

https://github.com/openai/codex/blob/8e271dc02b23d42827875019924be0f5005642b0/codex-rs/windows-sandbox-rs/src/elevated/runner_client.rs#L331-L364

The source comment states:

Sandbox users have no profile state that commands should inherit.

Microsoft documents that CreateProcessWithLogonW does not load the specified user's profile by default. LOGON_WITH_PROFILE or an explicit LoadUserProfile call is required:

https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createprocesswithlogonw

Windows credentials are associated with the user's credential set and profile/logon context:

https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/credentials-processes-in-windows-authentication

This provides a plausible explanation for the otherwise surprising result:

• interactive CodexSandboxOnline login: the stored SMB credential works;
• Codex-launched CodexSandboxOnline runner: the same account name is used, but its normal profile state is deliberately not loaded.

This appears to make storing an SMB credential interactively for CodexSandboxOnline ineffective for the actual runner.

The absence of profile loading may be an intentional security boundary. Therefore, globally changing the existing online runner to LOGON_WITH_PROFILE should probably be treated as a diagnostic experiment, not automatically as the preferred production fix.

3. Loading an unrestricted profile globally would introduce persistent state

Loading a Windows profile makes the user's HKEY_CURRENT_USER, profile configuration, application state, user certificate store, environment configuration, and other per-user state available to processes.

This can create task-to-task persistence. For example, one task could modify:

• user environment variables;
• application configuration;
• proxy configuration;
• PowerShell profile scripts;
• files under AppData;
• other user-specific startup or tool settings.

A later task using the same loaded profile could inherit those changes.

Profile loading itself is not equivalent to a complete interactive Windows desktop login, and it does not automatically execute every Windows startup mechanism. However, applications may consume profile-specific configuration after launch. For example, PowerShell executes current-user profile scripts unless it is started with -NoProfile:

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_profiles

This is why I do not think the existing CodexSandboxOnline identity should simply gain a normal persistent profile globally.

4. A separate credential-enabled sandbox identity may preserve the security boundary

A safer product design could introduce a third, explicitly selected sandbox identity in addition to the current online and offline identities, for example:

• CodexSandboxOffline: no network access;
• CodexSandboxOnline: network access without persistent user credentials;
• CodexSandboxCredentialed: an explicitly selected, dedicated identity for user-authorized authenticated network resources.

This would be selective rather than global:

• the normal user's profile remains unchanged;
• the existing online and offline identities remain unchanged;
• only tasks explicitly started in the credential-enabled mode load the dedicated credential profile;
• credentials and firewall rules can be limited to a selected SMB server or share.

The NAS credential should be entered by the user through Windows, outside the model conversation. I would prefer this over a Codex-managed SMB credential store.

Codex should not need to receive, serialize, encrypt, log, or otherwise store the NAS password in:

• prompts;
• config.toml;
• environment variables;
• command lines;
• Codex state databases;
• logs;
• tool input or output.

Windows already provides a credential boundary for this use case.

5. A Windows SMB credential is usable without normally exposing its plaintext password

For a credential stored as CRED_TYPE_DOMAIN_PASSWORD, Microsoft documents that the credential blob contains the password, but the blob can only be read by the Windows authentication packages. NTLM, Kerberos, and Negotiate can automatically use the credential for the named target:

https://learn.microsoft.com/en-us/windows/win32/api/wincred/ns-wincred-credentialw

Therefore, an ordinary sandbox process should be able to receive the capability to authenticate to the selected SMB target without being able to retrieve the plaintext password through normal credential APIs.

This is materially different from giving the password to the model or placing it in Codex-owned storage.

Generic Credential Manager entries have different read semantics and should not be used for this design. The implementation should require or document a target-specific CRED_TYPE_DOMAIN_PASSWORD.

The remaining security risk is intentional authorization rather than plaintext disclosure: the agent can use the permissions granted to the dedicated NAS account. The user should therefore remain responsible for assigning a suitably restricted NAS identity and share permission set.

6. A mandatory-profile-style baseline could limit task-to-task persistence

Windows supports Mandatory User Profiles. A mandatory profile is a preconfigured profile whose baseline cannot be permanently changed by the assigned user. Changes may be visible during the active session, but are discarded when the profile is properly logged off or unloaded:

https://learn.microsoft.com/en-us/windows/win32/shell/mandatory-user-profiles

This mechanism is assigned selectively to specific users; it is not inherently a machine-global setting.

A possible credential-enabled sandbox lifecycle would be:

1. Create a dedicated Windows sandbox account.
2. Prepare a minimal profile for that account.
3. Let the user store only the target-specific SMB credential through Windows.
4. Seal the profile as a mandatory or otherwise immutable baseline.
5. Load that profile only for an explicitly selected credential-enabled task.
6. Start the runner with a controlled environment.
7. Run PowerShell with -NoProfile and CMD with AutoRun disabled.
8. Restrict outbound access to the selected SMB server and required ports.
9. Terminate every process using the profile after the task.
10. Unload the profile and discard session changes.
11. Clean separate temporary and cache locations.
12. Start the next task from the same clean baseline.

A Mandatory Profile is not a complete filesystem snapshot. It would not revert:

• intended workspace changes;
• files written to the NAS;
• files written outside the profile;
• separately configured temporary directories.

Those areas still require normal sandbox enforcement and cleanup.

It also remains to be tested whether a target-specific CRED_TYPE_DOMAIN_PASSWORD stored in a Mandatory Profile works reliably when that profile is loaded non-interactively by the Codex runner. I could not find Microsoft documentation covering this exact combination.

If the native Mandatory Profile mechanism is incompatible with Credential Manager in this scenario, Codex could use an equivalent product-managed immutable profile baseline while still leaving the NAS credential itself under Windows protection.

7. Suggested safeguards for a credential-enabled sandbox

Possible safeguards include:

• explicit opt-in per task;
• a separate dedicated Windows account;
• no use of the normal user's profile;
• no browser, cloud CLI, GitHub, SSH, API, or unrelated credentials in the profile;
• only target-specific CRED_TYPE_DOMAIN_PASSWORD entries;
• no wildcard credential targets;
• per-server or per-share authorization;
• optional read-only versus read-write access;
• firewall access limited to the selected SMB endpoint;
• a controlled environment block instead of general profile inheritance;
• pwsh -NoProfile;
• prevention of persistent writes to profile startup and configuration locations;
• no uncontrolled concurrent tasks sharing one loaded profile;
• an explicit profile reset/recreation function;
• clear UI showing which remote identity and share permissions the task can use;
• no credentials in diagnostics, crash dumps, logs, or feedback bundles.

8. Unelevated mode requires a separate token-level investigation

The unelevated backend creates a restricted token from the current user's token and adds locally generated workspace capability SIDs:

https://github.com/openai/codex/blob/8e271dc02b23d42827875019924be0f5005642b0/codex-rs/windows-sandbox-rs/src/token.rs#L448-L505

The token uses WRITE_RESTRICTED. Microsoft documents that restricting SIDs participate in an additional access check for write operations:

https://learn.microsoft.com/en-us/windows/win32/api/securitybaseapi/nf-securitybaseapi-createrestrictedtoken

A remote NAS cannot normally resolve Codex's locally generated capability SIDs. This may make the restricted-token write model incompatible with a remote SMB filesystem even though the original user token and SMB credential are valid.

This remains a hypothesis. A focused test should compare, in the same Windows logon session:

1. access with the original user token;
2. access with the Codex-generated restricted token;
3. read, list, create, reopen, update, rename, and delete separately;
4. direct UNC and mapped-drive paths;
5. whether each failed request reaches the SMB server;
6. the effective enabled and restricting SID lists.

9. Missing authenticated SMB integration coverage

The existing Windows sandbox smoke tests create their workspaces under the local user profile:

https://github.com/openai/codex/blob/8e271dc02b23d42827875019924be0f5005642b0/codex-rs/windows-sandbox-rs/sandbox_smoketests.py#L54-L58

The UNC-related test I found verifies that a UNC link cannot be used as a sandbox escape:

https://github.com/openai/codex/blob/8e271dc02b23d42827875019924be0f5005642b0/codex-rs/windows-sandbox-rs/sandbox_smoketests.py#L578-L585

It does not test a legitimate authenticated SMB workspace.

A useful regression matrix would cover:

• direct UNC, extended UNC, and mapped-drive forms;
• short hostname and FQDN;
• Windows SMB and Samba/NAS targets;
• elevated and unelevated backends;
• read/create/reopen/update/rename/delete;
• shell operations and apply_patch;
• Credential Manager persistence across a new logon session;
• an interactive sandbox-account login versus a Codex-launched runner;
• a local command while an inaccessible SMB root is also configured;
• cleanup and profile reset between successive tasks.

Requested outcomes

The most useful outcomes would be:

1. Do not let one unsupported remote root break unrelated local sandbox commands.
2. Detect and report remote-root incompatibility explicitly.
3. Clarify whether authenticated SMB workspaces are officially supported.
4. Add authenticated SMB integration coverage.
5. Investigate profile/logon-session handling for the elevated online identity.
6. Investigate restricted-token behavior against remote ACLs in unelevated mode.
7. Consider a separate, explicitly selected credential-enabled sandbox identity rather than weakening the existing online identity globally.
8. Keep SMB password storage and plaintext handling within Windows rather than introducing a Codex-owned credential store.

AI assistance disclosure

I used OpenAI Codex to help design the diagnostic comparisons, inspect the public Codex source and official Microsoft documentation, analyze the security properties of the proposed alternatives, and draft this follow-up.

The tests were executed interactively in my affected environment and the observations were reviewed by me. No NAS password or other SMB secret was provided to Codex or included in this report.

Independent reproduction from the VS Code Codex extension on Windows.

Environment:

• Windows 10 Pro, build 19045, x64
• VS Code Codex extension 26.727.40816
• Bundled IDE-serving Codex runtime 0.146.0-alpha.9.2
• [windows] sandbox = "elevated"
• Authenticated SMB/UNC-backed workspace

Observed behavior matches this report closely:

1. The workspace is accessible normally outside the Codex native sandbox.
2. During elevated sandbox setup refresh, Codex canonicalizes the workspace to its UNC form and attempts to grant sandbox write ACEs.
3. The ACL operation fails with:

SetNamedSecurityInfoW failed: 5

1. Setup then reports:

helper_unknown_error: setup refresh had errors

1. The requested native operation fails before the target file is decoded or otherwise meaningfully processed.

Path aliases that refer to the same SMB share do not avoid the failure because sandbox setup operates on the canonical UNC-backed root.

A useful control was a completely local fixed-NTFS workspace under the same elevated sandbox configuration. In that configuration, sandbox setup completed successfully and no UNC root participated. This strongly separates the SMB/UNC sandbox-setup failure from later tool-specific processing.

No share ACLs, firewall settings, sandbox security boundaries, or server permissions were weakened during testing.

A separate test of the documented unelevated sandbox fallback encountered the split-writable-root refusal tracked in #32839, so in this managed workspace configuration neither Windows sandbox implementation currently provides a complete fallback.

Additional sanitized evidence from a VirtualBox Shared Folders workspace (no project content or private paths included).

Environment

• Windows 10 x64 build 19045
• Codex Desktop 26.803.10989.0
• Same failure was present in local logs from 26.727.6591.0 and 26.803.5235.0
• VirtualBox host and Guest Additions: 7.2.14 r174565 (matching)
• Workspace form: \\vboxsvr\<sanitized-share>\<repo>
• Codex task/session ID: 019ffb4d-57a4-7e12-9660-9b8fb49ff14c
• Diagnostic log: <CODEX_HOME>\.sandbox\sandbox.2026-08-13.log

Confirmed failure

• Normal host PowerShell and git status can read the repository.
• The VBox volume reports filesystem VBoxSharedFolderFS, remote drive type, flags 0x00000016.
• Flag FILE_PERSISTENT_ACLS (0x00000008) is absent.
• Elevated/workspace-write setup canonicalizes the root to \\?\UNC\VBOXSVR\..., attempts to grant the sandbox-group and capability-SID write ACE, then fails before command launch:

``
granting write ACE to \\?\UNC\VBOXSVR\... for sandbox group and capability SID
write ACE grant failed ... SetNamedSecurityInfoW failed: 1
setup refresh completed with errors
setup error: setup refresh had errors
``

• Win32 1 is ERROR_INVALID_FUNCTION; HRESULT form is 0x80070001.
• apply_patch therefore fails while preparing/reading an existing file; the repository file is never opened or modified.

Path/mode experiments

• A mapped drive for the same share is not a workaround. Win32 GetFinalPathNameByHandle resolves it back to \\?\UNC\vboxsvr\....
• subst only aliases a local path. A directory junction cannot target UNC (Local volumes are required). A local directory symlink requires extra privilege and still resolves to the same underlying UNC filesystem/security semantics.
• One-off windows.sandbox="unelevated" with built-in :workspace on local NTFS passed create/read/delete and ran as the interactive user.
• The same unelevated sandbox could not read the VBox UNC root: UnauthorizedAccessException, HRESULT 0x80070005; git -C <UNC> status exited 128 with permission denied.
• Local fixed NTFS passed create/open/rename/File.Replace/atomic same-volume move/temp/delete and supports the Codex sandbox.
• A sanitized helper that makes an independent local NTFS clone from the source worktree or, preferably, its upstream remote was tested end-to-end: source status unchanged, destination clean, origin preserved, NTFS confirmed.

Minimal reproduction

1. Expose any writable host folder to a Windows guest through VirtualBox Shared Folders.
2. In the guest, open \\vboxsvr\<share>\repro as a Codex Desktop project with workspace-write and [windows] sandbox = "elevated".
3. Create sample.txt outside Codex, then ask Codex to update it with apply_patch.
4. Observe helper_unknown_error: setup refresh had errors before command/file access and the SetNamedSecurityInfoW failed: 1 log above.
5. Map the share to a drive letter and repeat; final-path canonicalization returns UNC and behavior is unchanged.
6. Switch only a disposable invocation to unelevated: local NTFS works, UNC access is denied.

Source-level observation
Current main still queues ensure_allow_write_aces for write roots and pushes any error into refresh_errors, after which refresh bails:

• https://github.com/openai/codex/blob/main/codex-rs/windows-sandbox-rs/src/bin/setup_main/win.rs#L874-L918
• https://github.com/openai/codex/blob/main/codex-rs/windows-sandbox-rs/src/bin/setup_main/win.rs#L1006-L1011
• https://github.com/openai/codex/blob/main/codex-rs/windows-sandbox-rs/src/acl.rs#L390-L441

Root-cause assessment
This is an interoperability gap: the elevated Windows sandbox assumes every writable root can persist a Windows DACL, while VBoxSharedFolderFS explicitly does not advertise persistent ACLs. Simply ignoring the ACE error is probably not sufficient/safe because the restricted identity still needs access and the ACE participates in the sandbox capability boundary.

Suggested product behavior

1. Detect filesystem capability with GetVolumeInformation[ByHandle]W before ACL setup.
2. Do not let one unsupported UNC write root poison unrelated local sandbox commands.
3. For filesystems without FILE_PERSISTENT_ACLS, either use a brokered/path-validated I/O strategy, provide a supported non-ACL backend, or fail that root early with an actionable “use a local NTFS clone/workspace” message.
4. Preserve the security boundary; do not silently treat ACL failure as success.

Current safe workaround: open an independent local NTFS clone as the Codex project and use the normal central Git remote. Do not retain the VBox path as an additional writable root.

Independent reproduction on Codex Desktop for Windows, with an additional failure mode showing that an inaccessible remote writable root can poison apply_patch operations against a separate local NTFS workspace.

Environment:

• Codex Desktop: 26.803.10989.0
• Windows x64
• Sandbox mode: workspace-write / managed desktop sandbox
• Active writable roots included a local NTFS workspace, a mapped network drive, and an authenticated UNC share (paths and server names sanitized)

Observed behavior:

1. Host PowerShell can read the local workspace, mapped drive, and authenticated UNC share.
2. apply_patch can create a new disposable file inside the local NTFS workspace.
3. A subsequent apply_patch update of an existing file in that same local NTFS workspace fails before reading the target:

``
apply_patch verification failed: Failed to read file to update <local-workspace>\...:
fs sandbox helper failed ... windows sandbox failed:
helper_unknown_error: setup refresh had errors
``

1. Updating existing source files on the mapped drive fails with the same setup-refresh error.
2. Copying those source files into a staging directory on the local NTFS workspace does not help; updates to the staged existing files still fail.
3. An elevated host-shell read/hash check succeeds for all affected files, confirming that the files exist and ordinary host access is intact.
4. Repeated app restarts/tasks do not reliably resolve it.

This reproduces the inconsistency already described here: creation may succeed while read/update verification fails. It also confirms that the failure is not necessarily limited to the remote target itself. When remote writable roots participate in sandbox setup refresh, an unrelated apply_patch operation against local NTFS can fail too.

Practical impact:

• The agent can inspect the project through host PowerShell but cannot apply an already-prepared patch.
• UI/application development is blocked even though the target files are writable outside the Codex sandbox.
• Retrying consumes model usage/credits without progressing the task.
• The generic helper_unknown_error gives the user no actionable recovery instruction.

Expected behavior:

• A failing or unsupported remote writable root should not poison operations against unrelated local NTFS roots.
• The app should preflight each writable root, isolate the failing root, and report its exact path/filesystem capability.
• If remote roots are unsupported, the UI should provide an actionable recovery path before model work begins.
• A create/read/update/delete smoke test should run before an agent spends tokens preparing a patch.

Safe workaround requested:

• A documented way to start a task with only a selected local NTFS writable root, excluding unrelated configured remote roots from setup refresh.
• Clear guidance on whether opening a separate local-only project/task is sufficient, or whether remote roots must be removed from global/project configuration.

No ACLs, sandbox settings, network credentials, or security controls were weakened during testing.