Approval
What a Bot's permission mode has it ask first, let through by you before it runs. The card has three buttons: Allow once; Allow from now on (lets this one through and moves the Bot to the permission mode in which this kind no longer asks: auto for a change, allow-all for a setup change, as a line under the button says); Deny. Approval governs "the one step about to happen"; it cannot undo anything already done. A card that needs your key pasted (adding an HTTP MCP server, adding an endpoint that takes a key) comes up in every mode: it asks for a key only you have, not your consent.
Avoid: ConsentGate, gate
Permission mode
What a Bot may do without asking you, one of four (ADR 0092): read-only (reads files and looks things up; changes and setup changes are refused, with no card), ask first (every file write, edit or delete, every command and every setup change puts up an approval card), auto (writes files and runs commands, cards setup changes; the default), allow all (asks nothing). Reading files, listing, searching, looking things up on the web and calling configured MCP tools run in every mode. Whether a path is in the workspace does not matter. Settings › General sets the app's mode; the Bot panel can give one Bot its own, and a Bot without one follows the app. Only you set either: a Bot can set neither its own nor one for a Bot it hires. Read-only and ask first are written into the Bot's situation block. Refused in every mode (refusals, not approvals, so allow all too): reading or changing a local agent's sign-in, a recursive search of your whole home or / (see Bot shell), background tasks. Always allow on cards and its rule list in Settings are gone; rules already saved no longer apply.
Avoid: Always allow, rules letting a path or project through, a rule list per Bot, a Bot changing its permission mode, the workspace as a permission boundary, allow all reaching credentials
Dangerous action
A call a permission mode may stop: a change (writing, editing, moving or deleting a file, running a command) or a change to the app's setup (adding or changing an MCP server, including command·args / HTTP url·headers; creating an endpoint or changing an existing endpoint's URL, format or Anthropic workspace ID; a Bot changing a built-in prompt or putting it back on its default). Whether it waits for your approval is set by the Bot's permission mode; see Permission mode. Reads and calls to configured MCP servers are not dangerous actions. Deleting an MCP server, changing its usage note and adding or changing model names on an existing endpoint's list never put up a card, and are refused read-only. The default endpoint's URL and key cannot be changed, and it cannot be deleted.
Avoid: gate, ConsentGate, dangerous because outside the workspace
Outside the workspace
A path that, after realpath, does not fall under the workspace root prefix. A symlink inside the workspace follows its target: if the target is outside the workspace, so is the symlink. It decides how a path resolves, whether a file is attached and whether it can be annotated, not permissions: whether a Bot asks before reading or writing outside the workspace is up to its permission mode (ADR 0092); you opening a file or folder outside the workspace from a message needs no approval, and is read-only (ADR 0090); a file in a project session's directory is the exception: it can be saved, and annotated in that session (ADR 0095).
Avoid: string prefix only, judging by inode / hard link, outside means approval
Bot shell
A Bot's shell run: with no cwd it runs in the turn's ticket dir (in the workspace), it may reach anywhere, and whether it waits for approval is up to the Bot's permission mode alone. It is not a kernel jail. One exception: a recursive search (grep -r/-R, rg, find, du, ls -R) whose resolved root is your whole home folder or / puts up no card and is refused before it runs, with a suggested rewrite, in every permission mode; the judgment follows the resolved path (cd, ~, $HOME included), not the command string, a shell comment does not count, and a command it cannot parse — a pipe, a subshell, eval — is left alone; so is a search held to a few levels (find -maxdepth N, rg --max-depth N, N at most 3), which does not walk the whole tree. The same search scoped to the workspace root or a ticket dir runs as usual.
Avoid: whole-machine shell, sandbox, seatbelt, App Sandbox container as the workspace root, workspace shell, unconstrained shell, approval by the paths in a command, allow all lifting the search refusal