Choose the narrowest level that lets the task succeed. For unattended work that usually means read-only for reports and workspace-write for changes inside one project. Full access removes the guardrails for files, commands and network, so reserve it for isolated machines with nothing sensitive on them.
The three levels as one vendor describes them
OpenAI's documentation for scheduled tasks and automations, read on 19 October 2026, describes how unattended tasks behave under the default sandbox:
| Level | Behavior |
|---|---|
| Read-only | Tool calls fail if they need to modify files, use the network or work with apps |
| Workspace-write | Calls fail if they touch files outside the workspace or need network access. Specific commands can be allowed outside the sandbox through rules |
| Full access | Flagged as elevated risk, since changes, commands and network access happen without asking |
The page adds that tasks use an approval policy of never when organization policy allows it, and otherwise fall back to the approval behavior of the selected permission mode. Admins can enforce limits through admin requirements. Its security guidance is to begin with the narrowest access, grant network or broader file access only when needed, test prompts in a regular chat first, and review the first few runs before relying on them.
Fail closed is a feature
In a sandboxed mode, an action outside the allowed set fails instead of prompting. For unattended work that is the right default. A failed run is visible and fixable. An unprompted action in full access mode is not reversible by reading the logs.
Picking a level
- What does the task produce? A summary or report needs read-only. Code changes need workspace-write.
- Does it need the network? If yes, say exactly which hosts, instead of turning on full network.
- Does it touch files outside the project? If so, ask why. Prefer copying inputs into the workspace.
- What secrets are reachable from this environment? Environment variables and credential files in reach count as access.
- Is the machine disposable? Full access only belongs on throwaway or tightly isolated hosts.
Allow rules, carefully
Command allow rules let specific commands run outside the sandbox. Keep them exact. An allow rule for a package manager install command lets lockfile and install scripts run, which is a supply chain path. See should coding agents run install commands.
Worktrees keep changes apart
Both Anthropic and OpenAI describe running scheduled tasks in a separate Git worktree so automated changes do not collide with your unfinished work. The OpenAI page warns frequent schedules can create many worktrees, so archive old runs.
Test before you trust
Run the task manually and read what failed. Failures tell you what the task wanted but was denied, which is useful information for sizing access. Add only what you can justify.
Worked example: three tasks, three levels
Consider three tasks a small engineering team wants to schedule.
Task A: weekly dependency freshness report. It reads the lockfile and lists outdated packages. It writes nothing except its report text. Read-only fits. If the task needs registry lookups over the network, the team has a choice. Under a strict read-only sandbox, network calls fail. They could allow the registry host through whatever rules the product offers, or have a CI job fetch the data into a file the task reads. The second choice keeps the task's access smaller.
Task B: nightly lint fixer that opens a pull request. It edits files in one repository and runs the formatter. Workspace-write fits, in a worktree so edits stay separate from the developers' folders. It needs to run a few specific commands. The team adds exact allow rules for those commands, not for a shell. Network is off. The task pushes nothing, because pushing needs the network. A separate step, with narrower credentials, pushes the branch.
Task C: a task that migrates a database schema in a scratch environment. It needs wide file access and the network. The team considers full access. The documentation flags it as elevated risk because changes, commands and network access happen without asking. They decide to run it only on a disposable virtual machine with no real credentials and a throwaway copy of the data, and to destroy the machine after each run.
Decision table
| Question | Read-only | Workspace-write | Full access |
|---|---|---|---|
| Can it change files? | No | Inside the workspace | Anywhere the user can |
| Can it use the network? | No | No unless allowed | Yes |
| Failure mode on overreach | Call fails | Call fails | No failure, action happens |
| Good for | Reports, reviews | Local code changes | Disposable environments only |
The first two rows describe behavior in the vendor's documentation for unattended tasks. The last row is guidance.
Steps to pick and prove a level
- Run the task manually in the narrowest level.
- Read each failure. Ask whether the task truly needs what it was denied.
- Widen one capability at a time and record why.
- Test a hostile input. Confirm that the sandbox, not the model's good behavior, stops the unwanted action.
- Review the first several unattended runs.
Sandbox is not the only layer
A sandbox limits what a process can touch on a machine. It does not limit what connected apps can do on remote services, and it does not decide whether a model should act. Combine it with scoped connectors, branch protection, and logging. If your environment has secrets in files or variables inside the workspace, the sandbox will not hide them from the task, so move them out first.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how an assistant works within the access it has been given, and compare it with how narrow a sandbox you would choose for an unattended task.
Quick check
What happens when a read-only task tries to write?
Per the documentation, the tool call fails. The task does not get a prompt when running unattended.
Is full access ever appropriate?
On a disposable, isolated environment with no sensitive data or credentials, and with the risk accepted in writing.
Does workspace-write block network access?
Per the OpenAI documentation, calls fail if they need network access unless allowed. Check your own configuration, since defaults and admin requirements can differ.
Sources
Last reviewed: 19 October 2026.
