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

[SilverHandCZ]

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

26.721.4979.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 / Windows 11 Pro

What issue are you seeing?

Codex Desktop cannot reliably access projects located on a normal authenticated SMB share through UNC paths.

Example redacted writable roots:

\server.example.local\domains\PROJECT_A
\server.example.local\domains\PROJECT_B

With:

[windows]
sandbox = "elevated"

every sandboxed command fails before PowerShell starts. This also happens when the command is executed from a local TEMP directory because the sandbox setup refresh processes all configured UNC writable roots.

setup_error.json contains:

{"code":"helper_unknown_error","message":"setup refresh had errors"}

The sandbox log contains messages equivalent to:

granting write ACE to \?\UNC\server.example.local\domains\PROJECT_A for sandbox group and capability SID
write ACE grant failed: SetNamedSecurityInfoW failed: 5
setup refresh completed with errors

After changing the configuration to:

[windows]
sandbox = "unelevated"

and restarting Codex, local sandboxed commands work. However, the allowed UNC repositories remain inaccessible.

The following was verified from inside the unelevated sandbox:

• The process runs under the same Windows user as the host.
• DNS resolves the SMB server correctly.
• TCP port 445 is reachable.
• net use shows the mapped network share.
• Windows Credential Manager contains the SMB credential.
• Get-Item against the UNC path returns Access denied.
• git -C <UNC path> status returns Access denied.
• A requested UNC working directory is not used and PowerShell starts in its installation directory instead.
• The internal apply_patch operation can create a new file on the UNC share, but immediately fails to read or update that same file with os error 5.

Host PowerShell outside the Codex sandbox can access the same repositories normally.

What steps can reproduce the bug?

1. On Windows 11, connect to an authenticated SMB share available through a UNC path.

2. Open a Codex Desktop project located on that share and configure the UNC directory as an allowed writable root.

3. Set:

   [windows]
   sandbox = "elevated"

4. Restart Codex and run any sandboxed PowerShell command.

5. Observe that sandbox setup refresh fails before the command starts with SetNamedSecurityInfoW error 5.

6. Run the same test with a local TEMP directory as the working directory.

7. Observe that setup still fails because all configured UNC writable roots are processed.

8. Change the configuration to:

   [windows]
   sandbox = "unelevated"

9. Restart Codex.

10. Verify that local sandboxed commands work.

11. Run Get-Item or git status against the explicitly allowed UNC project.

12. Observe Access denied.

13. Use apply_patch to create a file on the share and then attempt to update it.

14. Observe that creation succeeds but reading or updating the file fails.

What is the expected behavior?

An explicitly allowed authenticated UNC workspace should remain accessible in at least the unelevated sandbox, which derives its restricted token from the current Windows user.

A failure to configure permissions for one UNC writable root should not prevent unrelated sandboxed commands from running from local directories.

File operations should behave consistently: if the sandbox can create a file, it should be able to read and update that file.

If authenticated SMB/UNC paths are not supported, Codex should detect them before setup and display a clear actionable message instead of the generic helper_unknown_error.

Additional information

Switching to the unelevated sandbox removes the repeated global setup-refresh failure, but UNC access still requires running commands outside the sandbox.

This appears related to issue #25422, but differs because this is a normal authenticated SMB share rather than a Cryptomator virtual filesystem, and both elevated and unelevated sandbox modes are affected.

Related issue:
#25422

Feedback ID:
019f9dbb-8f86-7d01-8949-935b52c5b7c6

[github-actions]

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

• Windows sandbox setup refresh fails for workspace on \\wsl.localhost UNC path #35380

Powered by Codex Action

[SilverHandCZ]

I don’t believe this report should be closed as a duplicate of #35380. The similar errors may indicate that both cases are caused by the same underlying bug in the application, but #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.

[TxBase]

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:

codex/codex-rs/windows-sandbox-rs/src/bin/setup_main/win.rs

Lines 830 to 909 in 8e271dc

	let mut grant_tasks: Vec<(PathBuf, String)> = Vec::new();
	let mut seen_deny_paths: HashSet<PathBuf> = HashSet::new();
	let mut seen_write_roots: HashSet<PathBuf> = HashSet::new();
	for root in &payload.write_roots {
	if !seen_write_roots.insert(root.clone()) {
	continue;
	}
	if !root.exists() {
	log_line(
	log,
	&format!("write root {} missing; skipping", root.display()),
	)?;
	continue;
	}
	let root_cap_sid_str =
	workspace_write_cap_sid_for_root(&payload.codex_home, &payload.command_cwd, root)?;
	let root_cap_psid = unsafe {
	convert_string_sid_to_sid(&root_cap_sid_str)
	.ok_or_else(|| anyhow::anyhow!("convert write root capability SID failed"))?
	};
	let need_grant =
	match path_write_aces_need_refresh(root, &[sandbox_group_psid, root_cap_psid]) {
	Ok(needs_refresh) => needs_refresh,
	Err(e) => {
	refresh_errors.push(format!(
	"write ACE check failed on {}: {}",
	root.display(),
	e
	));
	log_line(
	log,
	&format!(
	"write ACE check failed on {}: {}; continuing",
	root.display(),
	e
	),
	)?;
	true
	}
	};
	unsafe {
	LocalFree(root_cap_psid as HLOCAL);
	}
	if need_grant {
	log_line(
	log,
	&format!(
	"granting write ACE to {} for sandbox group and capability SID",
	root.display()
	),
	)?;
	grant_tasks.push((root.clone(), root_cap_sid_str));
	}
	}
	let (tx, rx) = mpsc::channel::<(PathBuf, Result<bool>)>();
	std::thread::scope(|scope| {
	for (root, root_cap_sid_str) in grant_tasks {
	let sid_strings = vec![sandbox_group_sid_str.clone(), root_cap_sid_str];
	let tx = tx.clone();
	scope.spawn(move || {
	// Convert SID strings to psids locally in this thread.
	let mut psids: Vec<*mut c_void> = Vec::new();
	for sid_str in &sid_strings {
	if let Some(psid) = unsafe { convert_string_sid_to_sid(sid_str) } {
	psids.push(psid);
	} else {
	let _ = tx.send((root.clone(), Err(anyhow::anyhow!("convert SID failed"))));
	return;
	}
	}
	let res = unsafe { ensure_allow_write_aces(&root, &psids) };
	for psid in psids {
	unsafe {
	LocalFree(psid as HLOCAL);
	}
	}

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:

codex/codex-rs/windows-sandbox-rs/src/elevated/runner_client.rs

Lines 331 to 364 in 8e271dc

	quote_windows_arg(&format!("--pipe-in={pipe_in_name}")),
	quote_windows_arg(&format!("--pipe-out={pipe_out_name}"))
	);
	let mut cmdline_vec = to_wide(&runner_full_cmd);
	let exe_w = to_wide(&runner_cmdline);
	let cwd_w = to_wide(cwd);
	let user_w = to_wide(&sandbox_creds.username);
	let domain_w = to_wide(".");
	let password_w = to_wide(&sandbox_creds.password);
	let mut si: STARTUPINFOW = unsafe { std::mem::zeroed() };
	si.cb = std::mem::size_of::<STARTUPINFOW>() as u32;
	let mut pi: PROCESS_INFORMATION = unsafe { std::mem::zeroed() };
	let env_block: Option<Vec<u16>> = None;
	let previous_error_mode = unsafe { SetErrorMode(RUNNER_ERROR_MODE_FLAGS) };
	// Sandbox users have no profile state that commands should inherit.
	let spawn_res = unsafe {
	CreateProcessWithLogonW(
	user_w.as_ptr(),
	domain_w.as_ptr(),
	password_w.as_ptr(),
	/*dwlogonflags*/ 0,
	exe_w.as_ptr(),
	cmdline_vec.as_mut_ptr(),
	windows_sys::Win32::System::Threading::CREATE_NO_WINDOW
	| windows_sys::Win32::System::Threading::CREATE_UNICODE_ENVIRONMENT,
	env_block
	.as_ref()
	.map(|block| block.as_ptr() as *const c_void)
	.unwrap_or(ptr::null()),
	cwd_w.as_ptr(),
	&si,
	&mut pi,
	)

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:

codex/codex-rs/windows-sandbox-rs/src/token.rs

Lines 448 to 505 in 8e271dc

	unsafe fn create_token_with_caps_from(
	base_token: HANDLE,
	psid_capabilities: &[*mut c_void],
	extra_restricting_sids: &[*mut c_void],
	) -> Result<HANDLE> {
	if psid_capabilities.is_empty() {
	return Err(anyhow!("no capability SIDs provided"));
	}
	let mut logon_sid_bytes = get_logon_sid_bytes(base_token)?;
	let psid_logon = logon_sid_bytes.as_mut_ptr() as *mut c_void;
	let mut everyone = world_sid()?;
	let psid_everyone = everyone.as_mut_ptr() as *mut c_void;
	// Exact order: Capabilities..., ExtraRestricting..., Logon, Everyone
	let mut entries: Vec<SID_AND_ATTRIBUTES> =
	vec![std::mem::zeroed(); psid_capabilities.len() + extra_restricting_sids.len() + 2];
	for (i, psid) in psid_capabilities.iter().enumerate() {
	entries[i].Sid = *psid;
	entries[i].Attributes = 0;
	}
	let extras_idx = psid_capabilities.len();
	for (i, psid) in extra_restricting_sids.iter().enumerate() {
	entries[extras_idx + i].Sid = *psid;
	entries[extras_idx + i].Attributes = 0;
	}
	let logon_idx = extras_idx + extra_restricting_sids.len();
	entries[logon_idx].Sid = psid_logon;
	entries[logon_idx].Attributes = 0;
	entries[logon_idx + 1].Sid = psid_everyone;
	entries[logon_idx + 1].Attributes = 0;
	let mut new_token: HANDLE = 0;
	let flags = DISABLE_MAX_PRIVILEGE | LUA_TOKEN | WRITE_RESTRICTED;
	let ok = CreateRestrictedToken(
	base_token,
	flags,
	0,
	std::ptr::null(),
	0,
	std::ptr::null(),
	entries.len() as u32,
	entries.as_mut_ptr(),
	&mut new_token,
	);
	if ok == 0 {
	return Err(anyhow!("CreateRestrictedToken failed: {}", GetLastError()));
	}
	// Additional restricting SIDs are identity markers, not capabilities. Deliberately exclude
	// them from the default DACL so possessing a route identity cannot grant object access.
	let mut dacl_sids: Vec<*mut c_void> = Vec::with_capacity(psid_capabilities.len() + 2);
	dacl_sids.push(psid_logon);
	dacl_sids.push(psid_everyone);
	dacl_sids.extend_from_slice(psid_capabilities);
	set_default_dacl(new_token, &dacl_sids)?;
	enable_single_privilege(new_token, "SeChangeNotifyPrivilege")?;
	Ok(new_token)

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:

codex/codex-rs/windows-sandbox-rs/sandbox_smoketests.py

Lines 54 to 58 in 8e271dc

	TIMEOUT_SEC = 20
	WS_ROOT = Path(os.environ["USERPROFILE"]) / "sbx_ws_tests"
	OUTSIDE = Path(os.environ["USERPROFILE"]) / "sbx_ws_outside" # outside CWD for deny checks
	EXTRA_ROOT = Path(os.environ["USERPROFILE"]) / "WorkspaceRoot" # additional writable root

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

codex/codex-rs/windows-sandbox-rs/sandbox_smoketests.py

Lines 578 to 585 in 8e271dc

	# 39. WS: UNC/other-drive canonicalization denied
	unc_link = WS_ROOT / "unc_link"
	other_to = Path(r"\\\\localhost\\C$")
	if make_symlink(unc_link, other_to):
	rc, out, err = run_sbx("workspace-write", ["cmd", "/c", "echo unc > unc_link\\unc_test.txt"], WS_ROOT)
	add("WS: UNC link escape denied", rc != 0, f"rc={rc}")
	else:
	add("WS: UNC link escape denied (setup skipped)", True, "symlink creation failed")

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.