Permissions and approvals
Understand what the native agent is asking to do before allowing it.
Read the requested action
Section titled “Read the requested action”Review file paths, commands, and service access before approving an action. A permission request is not proof that an operation is safe. Decline requests outside the task.
The native tool registry separates file edits, terminal commands, MCP tools, computer control, and project changes. For example, opening a project changes the active editor context; terminal approval also covers Git writes and persistent command execution.
Modes narrow the tool set
Section titled “Modes narrow the tool set”Read and Plan offer a narrower workflow than Agent. Debug has a bounded repair tool set. Subagents inherit the relevant execution profile and approval boundaries; delegation should not be treated as a way to bypass them.
Memory updates are not source-code edits and do not use the same approval category. Read-only investigation can still produce memory notes.
External tools have their own boundaries
Section titled “External tools have their own boundaries”Review each MCP connector before enabling it. Browser access can include authenticated pages. An ACP agent’s own permissions and runtime also matter; native-mode restrictions should not be assumed to govern every external agent.
Approval is not a sandbox
Section titled “Approval is not a sandbox”A tool confirmation does not mean every command runs in a fully isolated operating system. Do not assume a universal network block or filesystem sandbox. Work only in trusted projects, keep credentials out of prompts, and use separate environments for untrusted code.
See Privacy, MCP, and Other agents.