Windows: automations forced read-only when sandbox_mode is danger-full-access (parse_policy rejects DangerFullAccess)

Bug Report: Automations Forced Read-Only Despite Full-Access Config

Summary

Codex automations consistently enter read-only mode regardless of user
configuration. The agent cannot write files, create directories, or use
apply_patch — even when every relevant setting grants full access. This
makes automations effectively useless for any task that produces output.

Environment

• OS: Windows 11 Home 10.0.26200
• Codex model: gpt-5.5, reasoning effort xhigh
• Config location: %USERPROFILE%\.codex\config.toml

Relevant Config (verbatim)

approval_policy = "never"
sandbox_mode    = "danger-full-access"

[windows]
sandbox = "elevated"

[projects.'c:\users\scott\documents\codex\2026-05-04\make-universal-math-therom-prover-that']
trust_level = "trusted"

Every knob that controls write access is set to the most permissive value.
The project directory is explicitly trusted.

Observed Behavior

1. Automation starts. The agent receives the prompt and begins working.
2. Any filesystem write — apply_patch, shell mkdir, shell cat >file,

echo >file — silently fails or is blocked.

1. The agent reports the workspace is "read-only" and cannot produce output.
2. The automation's own memory directory also cannot be written to.
3. This happens on every automation run, not intermittently.

Expected Behavior

With sandbox_mode = "danger-full-access", approval_policy = "never",
and trust_level = "trusted", the agent should have unrestricted filesystem
access — matching the behavior of interactive (non-automation) sessions.

Root Cause (verified from source code)

I cloned the repo and traced the full execution path. The bug is a
mismatch between config resolution and sandbox execution on
Windows.

The Config Layer Accepts DangerFullAccess

The config system correctly resolves sandbox_mode = "danger-full-access"
to SandboxPolicy::DangerFullAccess, which maps to
SandboxEnforcement::Disabled (meaning: no sandbox needed).

File: codex-rs/protocol/src/models.rs:242-244

SandboxPolicy::DangerFullAccess => Self::Disabled,

The Windows Sandbox Layer Rejects It

When a command is executed, the dispatch in exec.rs:484-488 routes
through the Windows sandbox whenever SandboxType::WindowsRestrictedToken
is active:

#[cfg(target_os = "windows")]
if sandbox == SandboxType::WindowsRestrictedToken {
    return exec_windows_sandbox(params, sandbox_policy, ...).await;
}

Inside exec_windows_sandbox, the policy string is passed to
parse_policy() in windows-sandbox-rs/src/policy.rs:4-10:

pub fn parse_policy(value: &str) -> Result<SandboxPolicy> {
    match value {
        "read-only" => Ok(SandboxPolicy::new_read_only_policy()),
        "workspace-write" => Ok(SandboxPolicy::new_workspace_write_policy()),
        "danger-full-access" | "external-sandbox" => anyhow::bail!(
            "DangerFullAccess and ExternalSandbox are not supported for sandboxing"
        ),
        ...
    }
}

DangerFullAccess is explicitly rejected with anyhow::bail!.

This same rejection is repeated in:

• spawn_prep.rs:99-105 (common spawn context)
• elevated_impl.rs:153-158 (elevated sandbox capture)
• elevated/command_runner_win.rs:225 (runner process)

The Error Propagates Up

The ? operator propagates the error, which becomes:

CodexErr::Io("windows sandbox: DangerFullAccess and ExternalSandbox
are not supported for sandboxing")

Every tool call (shell commands, apply_patch) fails with this error. The
agent sees every command fail and reports the workspace as "read-only."

Why Interactive Sessions Don't Hit This

In interactive sessions, the SandboxType is determined by
should_require_platform_sandbox() in policy_transforms.rs:509-528.
When the file system policy kind is Unrestricted (as with
DangerFullAccess), this returns false, so SandboxType::None is used,
and commands go through the plain exec() path (no sandbox).

The bug is that automations don't follow this same path — they appear
to force SandboxType::WindowsRestrictedToken regardless of the
permission profile's enforcement setting.

Suggested Fix

In get_raw_output_result() (codex-rs/core/src/exec.rs:473-491), skip
the Windows sandbox when the policy is DangerFullAccess:

#[cfg(target_os = "windows")]
if sandbox == SandboxType::WindowsRestrictedToken
    && !matches!(
        sandbox_policy,
        SandboxPolicy::DangerFullAccess | SandboxPolicy::ExternalSandbox { .. }
    )
{
    return exec_windows_sandbox(params, sandbox_policy, ...).await;
}

Alternatively, parse_policy() in policy.rs could handle
DangerFullAccess by returning a maximally-permissive
WorkspaceWrite policy with all roots writable, rather than erroring.

Steps to Reproduce

1. Windows 11 with [windows] sandbox = "elevated"
2. Set sandbox_mode = "danger-full-access" and approval_policy = "never"
3. Create any automation that requires file output
4. Run the automation
5. Observe that every shell command and apply_patch fails

Impact

• Automations cannot create, modify, or save any files on Windows.
• This renders the automation feature non-functional for any

write-dependent task.

• The config system silently accepts danger-full-access without warning

that the Windows sandbox will reject it at runtime.

---

Submitted by: Scott
Date: 2026-05-04
Codex version: latest (as of 2026-05-04)