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.
3. The agent reports the workspace is "read-only" and cannot produce output.
4. The automation's own memory directory also cannot be written to.
5. 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)