Choose what your agent can do
5 minute read · Chats & Local Agents
Choose how much independence an agent should have for this conversation. For a first project, supervised work gives you a chance to review unfamiliar steps as they arise.
- Choose a level of access
- Know where providers differ
- Read an approval
- Choose how closely to supervise
- Handle an approval in parallel work
- Ask for a smaller action when needed
- Permission and approval controls
Choose a level of access
The composer offers Supervised, Auto-accept edits, Auto and Full access; Settings → Agents → Default access calls the second one Auto-edit. The selected provider receives the supported policy. In Auto, an authorized ordinary read or specifically scoped change through a native Vortex tool runs directly; the agent should not add a second confirmation step. For example, an authorized SELECT or a row update with a specific key can run directly. Native Vortex tool changes ask for confirmation in Supervised and Auto-edit. Auto-edit can accept local file edits through the provider; Plan is read-only. Provider support and the particular tool still determine what is available, and runtime approval requests or denials remain authoritative.
Planning helps you discuss an approach before implementing it. When you want actual changes, make that intent and the allowed project clear.
Know where providers differ
| Provider | Difference to check |
|---|---|
| Muse Code | Supervised and Plan are read-only: no file writes or shell commands. Auto-accept edits asks before each action, Auto uses Muse Code's own review, and Full access turns off its sandbox. |
| Google Antigravity | In Auto, Vortex reviews routine actions itself: reads, searches, edits and web fetches inside the project folders, read-only Git, common file commands with project paths, test and build tools, project scripts in package.json and scripts stored in the project run without a prompt. MCP calls, paths outside the project, .git, .env and credential folders, global installs and unrecognized commands still ask. Mass-destructive commands are refused. |
| Other providers | Auto follows the provider's own review behaviour, while authorized Vortex tool actions run directly. |
A paid action follows the same rules. In Auto and Full access, an agent video request is submitted without a separate approval once it fits the stated budget, so state the budget in your message.
Read an approval
An approval names an action or question for the current task and run. Inspect the command, destination or requested change. Accept when it matches your instruction, reject when it does not, or explain the boundary in a follow-up.
For example, allowing an agent to edit a local article page does not automatically authorize publishing it or sending real email. External MCP clients follow the explicit Confirm routine changes too setting. Credentials are resolved by Vortex rather than printed in resource listings. Vortex blocks known mass-destructive SQL and shell commands and FTP operations targeting protected root paths.
Use Stop to end the run; its pending approvals become invalid. A later run cannot reuse that approval. See follow-up delivery and MCP access.
Choose how closely to supervise
The execution modes are Supervised, Auto-edit, Auto and Full access, alongside the distinction between planning and ordinary work. They are passed to the chosen provider's protocol. Use Supervised when you are learning the project or working with unfamiliar resources. A mode name is not a promise that every provider treats every tool identically.
An approval card belongs to a specific task, run and request. Read its action details, any questions and the available responses. If it proposes a database write, remote command or external message, check the target and scope as well as the verb. A request to make a local page look better does not implicitly authorize pushing a repository or deploying it.
Handle an approval in parallel work
When several chats are active, open the exact chat requesting attention. A coordinator can surface a child's pending approval, but the user still answers the child's actual request. Approving an unrelated later run cannot unblock the earlier one. If you stop a run, its pending approvals are invalidated; a new run must ask again where needed.
Before granting access to an external MCP server, inspect what it can do and what account or resource it reaches. For native Vortex tools, Auto runs authorized routine reads and specifically scoped changes directly; Supervised and Auto-edit ask before changes, and Plan is read-only. External MCP clients follow their explicit confirmation setting. A tool being discoverable does not make its output or instructions trustworthy, and the SQL, shell and FTP root-path guards still apply.
Ask for a smaller action when needed
If a request is broader than intended, ask the agent to explain its purpose and propose a narrower step. For example: “Read the migration and show the intended schema change before running it.” Denying a write can still allow useful read-only inspection. After an approved change, verify the files, query result or preview behavior; an approval is authorization, not proof that the operation succeeded.
Permission and approval controls
The composer shows the current access mode. Read its explanation before changing it: mode names map to the selected provider's supported behavior and are not a universal promise that every action runs unattended.
An approval card belongs to a specific action in a specific run. Read its command/resource and consequence, then choose the displayed approval or rejection. A persistent approval has a wider effect than approving that single action. Currently only Computer Use offers one: Always allow remembers an app for the project, account and access mode on this computer; see Computer use. Answering an agent's clarification question supplies information; it does not automatically approve unrelated destructive work.
Stop requests cancellation and invalidates the active run's pending work as supported by the provider. It does not undo completed edits. An approval in a linked chat must be handled in that linked run. Authorization is limited to its stated scope: changing one identified row does not authorize changing every row, and editing a local file does not authorize publishing it. See MCP confirmation settings.