# Permissions and approvals

## 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

[Read and Plan](/editor/modes) offer a narrower workflow than Agent.
[Debug](/editor/debug-mode) has a bounded repair tool set.
[Subagents](/editor/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

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

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](/account/privacy), [MCP](/connect/mcp), and [Other agents](/connect/other-agents).