Claude Code and Codex without permission prompts, safely

The modes side by side

Claude Code: auto mode

Auto mode, in Anthropic’s words, lets Claude “execute without routine permission prompts. A separate classifier model reviews actions before they run, blocking anything that escalates beyond your request, targets unrecognized infrastructure, or appears driven by hostile content Claude read.” The classifier runs on Claude Sonnet 5 by default, never sees tool results, so a hostile web page can’t argue with it directly, and approves reads and edits in your project without a call. Its default blocks include curl | bash, force pushes, git reset --hard, destroying infrastructure, printing a live token, and starting another agent with --dangerously-skip-permissions; it allows installing what your lockfile declares, read-only web requests and pushing to the repository you’re in. Telling it “don’t push” works, but that boundary can be lost when the conversation is compacted, so a deny rule is the reliable form. After three blocks in a row or twenty in total it hands back to you.

It works on every plan, with a recent model (on Anthropic’s own API, Opus 4.6 or later, Sonnet 4.6 or later, Haiku 5.5 or a Fable model), and on Pro, Max and Team its classifier calls don’t count toward your limits. Anthropic’s own caution: “Auto mode reduces permission prompts but does not guarantee safety.”

Claude Code: --dangerously-skip-permissions

The flag, the same as --permission-mode bypassPermissions, runs every tool call without asking. A few things still stop it: your deny rules and ask rules, and deleting a critical path such as the home folder or the project itself, which asks you to approve it and is refused if two minutes pass with no answer. On Linux and macOS it refuses to start as root or under sudo (“--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons”), the first interactive run asks you to accept responsibility, and permissions.disableBypassPermissionsMode set to "disable" locks it out. Anthropic’s line on where it belongs: “Only use this mode in isolated environments like containers, VMs, or dev containers without internet access, where Claude Code cannot damage your host system,” because it “offers no protection against prompt injection or unintended actions.”

Claude Code’s sandbox

The sandbox is a boundary the operating system enforces around the shell commands Claude runs, and is off by default. Once on, writes are limited to the project and a temporary folder, and the network goes through a proxy whose list of allowed hosts starts empty. Reads are not limited by default: they cover “most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials,” which sandbox.filesystem.denyRead closes. On Linux it needs bubblewrap and socat, and on Ubuntu 24.04 an AppArmor profile for bwrap when sysctl kernel.apparmor_restrict_unprivileged_userns prints 1.

Two defaults to change before relying on it. If the sandbox can’t start, Claude Code runs commands without it unless sandbox.failIfUnavailable is true. And a command that fails inside it may be retried outside it, which "allowUnsandboxedCommands": false switches off. It also covers shell commands only: “Claude’s file tools, MCP servers, and hooks run outside it,” which is why Anthropic says the sandbox alone “is not sufficient for fully unattended runs.”

Codex: the sandbox is the default

Codex works in two layers, a sandbox mode (what it can technically do) and an approval policy (when it stops to ask). Started in a git repository it picks the Auto preset, workspace-write with on-request: it edits and runs commands in the project and the temporary folders, keeps .git read-only, has no network, and asks to go further. -a never keeps the same box and never asks, returning failures to the model. codex exec, the scripted form, starts read-only, so add --sandbox workspace-write for a run that edits; it also wants a git repository unless you pass --skip-git-repo-check. Reads are not restricted, and network_access = true under [sandbox_workspace_write] turns the network fully on.

OpenAI’s docs still call --full-auto a deprecated flag that prints a warning, but Codex 0.160.0 rejects it outright (“unexpected argument '--full-auto' found”) and the current source has no such flag. On Linux the sandbox is bubblewrap plus seccomp, and Ubuntu 24.04 may need OpenAI’s extra AppArmor profile, the Codex on a Linux server guide’s subject. Inside a Docker container the sandbox may not start at all, and OpenAI’s advice there is to make the container the boundary and run --sandbox danger-full-access in it. The no-checks flag is “EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed,” in the CLI’s own help, and the docs add: “avoid --dangerously-bypass-approvals-and-sandbox unless you are inside a dedicated sandbox VM.”

What we saw running both unattended

On October 9, 2026, we gave both agents the same three bug fixes in open-source projects and let each work alone in its sandboxed mode: Claude Code non-interactive, in acceptEdits with the sandbox on and its retry outside switched off; Codex in workspace-write with approvals off; both on Ubuntu 24.04. A first check showed both boxes holding: asked to fetch a web page, Claude Code’s proxy refused the connection with a 403, and Codex couldn’t resolve the host. Then the real work showed where each box pinches:

• Codex’s sandbox broke the projects’ own tests. In Commander.js, child processes the tests start lost their output and synchronous spawns got EPERM on standard input, so Codex wrote a temporary adapter outside the project to get the suite through. In Black, the sandbox refused to create local sockets, so the daemon tests failed and the asynchronous tests hung; Codex said it could not finish the full run. Its fixes were right: run outside the sandbox afterwards, every test passed.
• Claude Code’s checks refused some commands, not the tests. Its sandbox ran both full suites: all of Commander.js’s tests passed, and in Black two caching tests failed the same way on the untouched checkout and passed outside the sandbox. Its permission layer turned down a handful of commands it couldn’t check before running, such as a compound command with quoted text or a variable in it, and a file write outside the project; the model ran them again in simpler forms.

So an unattended agent in a sandbox will meet the sandbox, and a project whose tests start processes or open sockets may need its rules widened, or a machine that is itself the boundary.

Where an agent without prompts belongs

Both makers put the same condition on running with no checks: a boundary around the whole agent, not just its commands. Anthropic lists a dev container, any container or VM, or its sandbox runtime for unattended runs, and “a dedicated virtual machine” for an untrusted repository; OpenAI says “a dedicated sandbox VM.” Both warn that a container doesn’t protect what is inside it: with the checks off, “a malicious project can exfiltrate anything available inside the devcontainer, including Codex credentials,” and Anthropic’s page says the same of Claude Code’s login. So the rule is about what the box holds. An agent running without prompts can read, change and send anything on its machine, its own sign-in included, so it should run on a machine whose contents you would hand it: the project, its tools and the agent’s own login, not your SSH keys, your cloud credentials or your other work.

A computer of its own covers the first half of that: what the agent can reach is what you put there. Everpod’s developer pod is that machine ready made: a cloud computer that is yours, always on, with your pick of Claude Code, Codex, OpenCode and Pi installed, reached only through your own private network, from $24 a month. It accepts no incoming connections from the open internet: no open ports and no public SSH. A server your agent starts is reachable from your devices and from nowhere else. By default the machine does not start connections to your other devices. A developer pod is one machine that stays yours: what you installed, the servers you left running, Docker and your work in progress are where you left them tomorrow. It does reach the internet, as a working agent’s machine has to, so the other half of Anthropic’s condition, “without internet access,” isn’t met by the machine alone: for work that reads untrusted pages or repositories, auto mode or the sandbox’s network rules still earn their place there.