Skip to main content
Approval mode controls confirmation prompts for the current session. It is separate from the agent mode: Act and Debug determine which tools are available, while the approval policy determines which available tool calls wait for you. Use the approval control beside the composer, or run one of these commands:

​
Approval modes

The default mode is Manual. Slash-command aliases are:
  • /always-confirm, /always-ask, or /strict;
  • /manual-confirm;
  • /auto-confirm, /auto-approve, or /approve.
Skip all removes ordinary confirmation prompts. It does not bypass mode restrictions, .embedderignore, protected Git metadata, managed-work restrictions, or a tool that requires explicit consent. Hardware arbitration and other hard safety checks also remain active.

​
Respond to a confirmation

An inline confirmation shows the tool, affected paths, and an external or destructive warning when applicable.
  • Allow once runs this call.
  • Allow always grants matching calls in the same permission category for the rest of the session.
  • Reject cancels the request. Rejecting one request also rejects other pending confirmations in that session.
In VS Code, the keyboard choices are Y, A, and N. Some confirmations intentionally omit Allow always. Session grants are not persistent allowlist entries. Use /approvals when you want a command rule to survive a new session.

​
What Manual allows

Manual mode permits ordinary read tools without a generic confirmation. For shell commands, it evaluates:
  1. hard policy blocks, such as protected Git metadata and .embedderignore;
  2. whether a referenced path leaves the project;
  3. your persistent deny and allow rules;
  4. the built-in read-only command rules.
The built-in groups cover:
  • directory navigation and file listing;
  • file, object-file, host, process, and device inspection;
  • environment and tool-location queries;
  • text search and formatting;
  • read-only version-control, package, container, and cluster queries;
  • build-tool help and dry runs;
  • compiler, flasher, and debug-probe information queries that do not program or erase a target.
Run /approvals to search the exact built-in entries and test a command. The tester reports whether the command runs or asks, why, and any paths detected outside the project.
Turning off the built-in list makes every shell command ask in Manual mode. It does not make ordinary file reads ask. Use Always ask for that behavior.

​
Persistent rules

Embedder reads two files: If EMBEDDER_APP_DIR is set, the global file is stored in that directory instead of ~/.embedder. A global file can contain:

​
Command rules

autoApprove adds commands that may run without a prompt in Manual mode. A rule matches the command and any positional prefix you include:
  • west matches west build and west flash;
  • west build matches west build -p always;
  • west build does not match west flash;
  • a bare program name also matches an absolute system path to that program, but not a repository-local path such as ./west.
Each entry is one command, not a shell line. Entries cannot contain ;, &, |, backticks, $, redirection operators, or line breaks. neverAutoApprove has priority over your grants and the built-in list. Use it to make a built-in command ask. For example, denying env prevents an unattended environment dump.

​
Paths outside the project

Shell commands that name a path outside the project ask even when the command itself is allowlisted. Add a specific directory to allowOutsideProject when a trusted toolchain or SDK lives elsewhere. Entries must be absolute paths. Embedder rejects the filesystem root and your entire home directory because either value would disable the boundary rather than scope it. Allowing an external path removes only the path boundary. The command must still match a built-in or personal command rule.

​
Project policy can only narrow

The project file is shared with the repository, so it cannot silently grant execution on a cloned project. A project policy can:
  • add neverAutoApprove entries;
  • set useBuiltinSafeCommands to false;
  • request an autoApprove command or outside-project path for you to review.
Requested grants are shown in /approvals as not granted. Select Add to mine to copy an exact request into your global file. During policy resolution:
  • either layer can turn the built-in list off;
  • global and project deny rules are combined;
  • only global command grants and outside-project paths take effect.
If a policy file is invalid, Embedder ignores the whole file and reports the parse error in the Files tab. It does not overwrite an invalid file from the approvals editor. An allowlist answers whether a tool call may run without another generic card. It does not expand the task you asked the agent to perform. For example, allowing a flasher executable does not authorize programming an arbitrary target. The agent still needs a request that identifies the intended operation, and dedicated hardware tools can require their own target and safety confirmation.
Last modified on August 24, 2026