Bound Authority With Sandbox and Approvals

Access is not one switch. A task may be allowed to read a repository but not edit it, edit one workspace but not another, run installed commands but not download packages, or inspect an external service without changing it. An approval for one action should not silently grant authority over every system the agent can name.

Write authority in terms of targets and effects. Which folders may change? May the task use the network? Which connected services are in scope? Is it read-only, draft-only, or allowed to publish? Which operations need a human to review the exact target first? This is much clearer than asking whether Codex is generally trusted.

A sandbox limits what commands and file operations can reach. It turns accidental or misunderstood actions into contained failures instead of broad changes. When a legitimate command is blocked, the lesson is not automatically that the sandbox is wrong. First check whether the task can succeed with a narrower path, a read-only alternative, or an existing approved tool.

Local and cloud environments may enforce boundaries differently, so inspect the current surface's official controls. The durable practice is to start with the minimum needed access, observe the specific blocker, and widen only the exact capability required for the named task.

For a fresh setup, use the newer permission-profile engine: `default_permissions = ":read-only"` for inspection, `default_permissions = ":workspace"` for ordinary workspace editing, or a named policy under `[permissions.<name>]` for narrower filesystem and network rules. The colon-prefixed names are permission profiles. They are selected by `default_permissions`, not by the CLI `--profile` flag.

The compatibility engine is the older `sandbox_mode` system: `read-only`, `workspace-write`, or `danger-full-access`, optionally paired with `approval_policy` values such as `untrusted`, `on-request`, and `never`. It is selected by `sandbox_mode`, `[sandbox_workspace_write]`, or `--sandbox`. The two engines do not compose: never load `default_permissions` or `[permissions]` together with older sandbox settings. Any loaded `sandbox_mode` or `--sandbox` flag makes Codex use the older engine. In the interactive CLI, `/permissions` helps inspect the active boundary, but it does not make a mixed configuration valid.

When Codex is denied, read four things: the attempted command or tool, the target path or network destination, the active sandbox, and whether an approval channel exists. If the requested effect is outside the task, keep the denial. If the task genuinely requires it, ask Codex for the narrowest alternative and review the exact escalation rather than changing the whole session to full access.

A denial can be the intended test. In a read-only session, request a harmless file creation and confirm it fails. In `workspace-write`, request the same file inside the repository and confirm it succeeds, then ask for a sibling-directory write and decline the escalation. In non-interactive execution, a newly required approval cannot be answered, so the action fails and must be represented in the run receipt.

A useful approval request explains the command or action, exact target, expected effect, why the current boundary blocks it, and whether the change is reversible. Review that substance. Repeatedly clicking approve trains you to ignore the moments where human judgment is most valuable.

Broad reusable approvals are appropriate only when the command family, target scope, and effect are genuinely predictable. Installing dependencies in one known project is different from approving arbitrary package-manager commands across the computer. Publishing one named site is different from granting unrestricted provider mutations.

Secrets should enter through an approved credential or environment mechanism, not prompts, source files, screenshots, or logs. The agent often needs to know that a variable exists, but rarely needs to print its value. If a secret is exposed, treat it as compromised and rotate it rather than merely deleting the visible line.

External communication, production changes, purchases, account changes, and actions affecting other people require explicit authority. Drafting an email is not sending it. Preparing deployment assets is not publishing them. Keep the transition from preparation to consequence visible and reviewable.

A completion receipt should state which permissions were used, which external systems changed, and which consequential actions did not occur. For production work, include a rollback target and independent verification. For sensitive data, include evidence that values were not written to source or logs.

Safety is not a separate phase added after implementation. The authority plan shapes the implementation itself: read before write, draft before send, stage before publish, test a migration before applying it, and resolve exact deletion targets before removing anything.