I imagine most people enable Codex's "Approve for me" mode or Claude's Auto mode for efficiency. Thinking back, when I first started using Claude Code, I really did review nearly every command it issued, at most enabling "Accept edits" mode. But doing this for an extended period was far too inefficient, and it was unsuitable for multitasking.

A sandbox is intended to provide an isolated environment, but "Approve for me" mode is practically no different from not using a sandbox at all. At present, perhaps the sandbox's greatest benefit is simply that it sounds safer: the Agent is locked behind a door, but the key is handed to it, leaving the user with nothing to do except hope the AI does not go haywire. Even more unexpectedly, when I asked Claude today to search for information about sandbox configuration, I learned that "Claude Code's sandbox does not run on native Windows," while Codex has implemented its own Windows sandboxes (elevated and MXC).

Is there any way to achieve automation in the strict sense while still ensuring data security? It seems the safest option is to set up a separate machine or virtual machine specifically for running these Agents, though that is somewhat inconvenient. The good news, however, is that both Codex and Claude allow you to configure a custom prompt for the classifier model responsible for approvals, which can prevent access to sensitive files to some extent.

Codex Desktop

For Codex, when approvals_reviewer = "auto_review" (that is, "Approve for me" mode) is used, extra_policy only takes effect when approval is required. Operations already permitted within the sandbox are not submitted to the AI for review.

# ~\.codex\config.toml

default_permissions = "safe"
approval_policy = "on-request"
approvals_reviewer = "auto_review"

[windows]
sandbox = "elevated"

[features]
# Disable MXC because it rejects the config when FUSE drives (e.g. rclone mounts) are present alongside deny rules.
prefer_mxc = false

[permissions.safe]
extends = ":workspace"

[permissions.safe.filesystem]
glob_scan_max_depth = 4
'~\.ssh'                        = "deny"
'~\DeniedPath'                  = "deny"

[permissions.safe.filesystem.":workspace_roots"]
"**/.env*" = "deny"

[auto_review]
extra_policy = """
## Protected directories (always deny)
Deny any escalation request that would read, list, copy, move, modify, or delete
contents of the following directories, regardless of the stated justification,
and regardless of whether access is direct or indirect (via scripts, wildcards,
environment variables, path aliases, or child processes):
- C:\\Users\\<user>\\.ssh
- C:\\Users\\<user>\\DeniedPath
## Agent configuration (always deny)
Deny any escalation request that would create, modify, rename, or delete
Codex or Claude configuration, rules, or policy files, including:
- C:\\Users\\<user>\\.codex\\config.toml
- C:\\Users\\<user>\\.codex\\rules\\
- C:\\Users\\<user>\\.claude\\settings.json
- C:\\ProgramData\\OpenAI\\Codex\\requirements.toml
If the user genuinely needs access, the main agent must stop and ask the user
to perform the action themselves.
"""

# %ProgramData%\OpenAI\Codex\requirements.toml
[windows]
# Block MXC entirely, since the desktop app may still pick it despite prefer_mxc = false.
allow_mxc = false

Claude Code Desktop

For Claude Code, the deny rules under permissions only block the built-in read and write tools; they do not prevent reading and writing through the shell. Unlike Codex, however, the hard_deny rules in Auto mode still take effect even though Claude Code does not support sandboxing on native Windows.

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",        "Edit(~/.ssh/**)",
      "Read(~/DeniedPath/**)",  "Edit(~/DeniedPath/**)",
      "Read(**/.env*)",
      "Edit(~/.claude/settings.json)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "autoMode": {
    "hard_deny": [
      "$defaults",
      "Protected directories: never read, list, copy, move, modify, or delete contents of the following directories, regardless of the stated justification or user request, and regardless of whether access is direct or indirect (via scripts, wildcards, environment variables, path aliases, or child processes): C:\\Users\\<user>\\.ssh, C:\\Users\\<user>\\DeniedPath. Also never create, modify, rename, or delete Claude Code's own settings files (C:\\Users\\<user>\\.claude\\settings.json and C:\\Users\\<user>\\.claude\\settings.local.json), though reading them is allowed. If the user genuinely needs access, stop and ask the user to perform the action themselves."
    ]
  }
}