AI coding agent sandbox permissions and unattended work

Recommendation: A task instruction states the scope an AI coding agent should stay within, but only the execution environment enforces it. Before an unattended run, each capability (files, commands, network, credentials, runtime, publishing) gets a named enforcing mechanism and a harmless check that shows the boundary holds.

Instructions, approvals, and enforcement

OpenAI's Codex documentation separates the sandbox policy, which constrains what model-generated commands can do, from the approval policy, which controls when Codex pauses for human approval (Codex agent approvals and security). A project brief that excludes a database expresses intent. Giving the task no credential and no route to that database enforces it.

A permission prompt and a blocked operating-system action are different events. The first asks for a decision, and the second reports an enforcement result. The run log records which one happened, so a later operator can tell whether the task needs more access, a corrected command, or a smaller scope.

A boundary inventory

Before an unattended run, a short inventory connects each capability to the decision behind it and the evidence that decision leaves. The table is a planning aid, not an agent configuration schema.

Question to resolve is answered before the run starts, and Evidence to retain is what the run log keeps so the answer can be checked afterwards. The inventory exposes missing decisions, and it stops a single word such as isolated from standing in for six unrelated controls.

Coverage differs between products

Claude Code's sandbox documentation describes the sandboxed Bash tool and names the tools and command paths that sit outside that boundary, while its permission documentation covers a separate layer of tool authorization (Claude sandbox coverage, Claude permissions). Enabling a shell sandbox therefore does not by itself enclose the whole agent process. Gemini CLI documents several sandbox mechanisms, including platform-specific and container-based approaches (Gemini sandboxing), so the configured mechanism and its effective settings on the execution host matter more than a statement that sandboxing exists.

These differences are not a ranking. They define what an operator records before comparing behavior or allowing an unattended task, because a control that covers one command path can leave another path under different policy.

A harmless boundary check

A rehearsal on disposable data checks three things: an allowed write inside the task directory, an attempted write outside the approved roots, and each required network destination. A write boundary can still permit reads elsewhere, so the check names the operation it expects to fail. A successful read proves nothing about writes. The record keeps the command, the observed result, and the policy the command exercised.

For Codex, the command line reference documents explicit sandbox and approval flags, and an inspection session can make both visible in its invocation:

codex --sandbox read-only --ask-for-approval on-request

• --sandbox read-only: selects the sandbox policy for model-generated shell commands. In read-only, Codex reads files and runs commands inside the sandbox without making edits. The other values are workspace-write and danger-full-access.
• --ask-for-approval on-request: controls when Codex pauses for human approval. With on-request, commands the sandbox allows run without approval, and actions outside it, such as network use, ask first. The other value is never.

Network access is off by default. In workspace-write mode it stays off unless the Codex configuration enables it:

[sandbox_workspace_write]
network_access = true

[sandbox_workspace_write] is the configuration section for that sandbox mode, and network_access = true turns network access on for commands in that mode (Codex agent approvals and security). The invocation above is an inspection example, not a complete unattended configuration: account policy, platform support, and other active settings still need checking on the execution host.

Network access and credentials

The task environment carries only the credentials the task needs. Reachability and authorization are separate checks: a reachable domain does not authorize an operation on its service, and a valid credential does not prove that the endpoint is reachable. A private package download, for example, fails either because the registry host is blocked or because the package token lacks access. Replacing both controls with broad access hides the original cause and enlarges the task's reach.

When approval becomes necessary during an unattended run, the runner stops and preserves the failed action for review instead of broadening permissions, which would change the authorization decision. A task that ends incomplete but reports the exact boundary that stopped it is a useful result.

Containers, mounts, and shared hosts

Docker's security documentation covers the daemon, host access, privileges, and the implications of exposing control interfaces (Docker Engine security). A container's isolation depends on its configuration: a mounted host directory or a privileged control channel changes what the process can reach.

The middle branch of the map shows a bind mount, -v /host/dir:/work: the host directory /host/dir appears inside the container at /work and stays writable unless the mount is read-only (:ro). The right branch is the default case on a shared host, where processes under the same operating-system user can reach sibling directories, local ports, and environment variables.

For coding agents, the review covers mounts, shared credentials, network services, and the operating-system account. Separate Git worktrees organize source changes, but they are not a process or credential boundary (Git worktree model). The Git worktrees guide covers what worktrees isolate, and the agent tool permissions article covers the design side of tool access.

Completion evidence for unattended work

An unattended result contains the starting commit, the resulting patch, the commands run with their exit statuses, the failed attempts, and any unresolved approval. The final agent message points to that evidence. It never turns a planned test into a passed test or a proposed deployment into a live service.

The handoff also needs durable repository state. A terminal session, a host snapshot, and a pushed branch preserve different state, and the cloud agent guide covers that execution-host decision.

Oyren provides browser VS Code and a terminal on a Linux Codespace, with agent authentication and runtime handled separately. The Codespaces page describes that environment, and the permission boundary still depends on the selected agent and its task configuration.