Permissions and Approvals
Permissions determine which resources an agent can reach. An approval determines whether a particular prepared action may proceed. A model proposing an action does not grant that action authorization.
Three permission modes
| Mode | Read | Write | File changes | Commands | Best suited to |
|---|---|---|---|---|---|
| Default | Current workspace | Current workspace | Approval each time | Approval each time | First use, important projects, read-only analysis |
| Full | All locations | All locations | Automatically approved | Automatically approved | Fully trusted, controlled tasks |
| Custom | Workspace or all locations | Denied, workspace, or all locations | Optional automatic approval | Optional automatic approval | Everyday work requiring precise boundaries |
Full permissions still deny operations that the system classifies as catastrophic, unsupported, or beyond a fixed safety boundary. The command-safety ceiling for Custom permissions always remains in Protected mode, even if you enable automatic approval.
Configure available modes
- Open “Settings → General.”
- Default permissions are always available and cannot be disabled.
- Enable Full or Custom permissions when needed.
- For Custom permissions, configure read access, write access, automatic file approval, and automatic command approval separately.
If writing is set to “Deny writes,” automatic file approval has no effect. Start with the narrowest scope and expand it temporarily for a specific task.
Select permissions for one task
Before sending, use the permission selector below the composer. The interface confirms the risk again when you select Full permissions. Once a run begins, its permissions are frozen. Changing Settings in the middle of a run does not automatically give an in-progress action broader access.
Without a selected project, many file or command operations also require an explicit valid directory and sufficient write scope. A permission mode does not make an arbitrary model-supplied path trustworthy.
What to check on an approval card
Different actions show different details, but review at least:
- Action type: A file edit, command, Office output, skill script, MCP tool, or browser risk.
- Target: Whether the file, directory, command, MCP server, web page, or local resource matches the task.
- Parameters and impact: Whether the action deletes, overwrites, uploads, downloads, submits a form, or incurs a charge.
- Source: Whether the request came from the root agent, a particular subagent, a skill, or an MCP server.
You can approve or deny an action. When denying, you can add an explanation so the agent can try another approach. Some file and command approvals offer “Remember for this run.” This applies only to the current run and the corresponding action scope; it is not permanent authorization.
Specialized authorizations do not replace one another
- Saving MCP configuration, authorizing a local process to launch, enabling the connection, and approving a tool call are four separate actions.
- Allowing managed-browser automation does not approve uploads, downloads, private-network access, or page scripts.
- Installing a skill does not automatically approve its scripts or file writes.
- Opening a page manually in the right sidebar does not authorize an agent to control it.
- Notifications and attention states are reminders; they cannot approve an action.
Additional risks for scheduled automations
An automation may run while you are not looking at the screen. Its current permissions are frozen when you create or edit it:
- Disabling Full or Custom mode prevents future runs that use that mode from starting.
- Re-enabling the mode later does not automatically repair tasks that are already blocked; edit and save the task.
- Changing individual Custom-permission settings does not automatically narrow tasks already saved. To reduce access, update each relevant task or disable the mode first.
- Pausing a task prevents future schedules but does not cancel a run that is already active or awaiting approval.
See Scheduled Automations for details.
Permissions are not a system sandbox
Captain Who validates paths, command structure, risk, and frozen parameters, but it is not a general-purpose operating-system container. A permitted program may still access resources that the operating system allows the current user to access. Continue to use isolated environments, version control, and least privilege for unfamiliar repositories, third-party skills, MCP servers, and websites.