Skip to main content
The permission system intercepts every tool call an agent makes and produces one of three decisions: allow the tool to execute, deny it, or ask the user for confirmation. The decision is driven by three components working together, each covered in its own page: The sequence diagram below shows how a tool call flows through the system. An ASK decision surfaces to the user together with auto-generated suggested rules; accepting one persists it, so future identical calls are handled without prompting:

Decision Matrix

Every call walks the same decision points from top to bottom, and the first decisive answer wins. The matrix below shows, for each mode, what each decision point produces. A “skipped” cell means the mode does not consult that point at all; when a point stays silent (no rule matches, or the tool returns PASSTHROUGH), evaluation continues downward until the fallback: How to read the rows:
  • ① / ② / ⑤ Rules: user-configured patterns, evaluated deny → ask first, allow late. Deny and ask rules are honored in every mode (in DONT_ASK, an ask rule converts to DENY because no user is available to answer).
  • ③ Read-only fast path: if the specific invocation is factually read-only (check_read_only(tool_input)), it is auto-allowed in every mode. The check is per-invocation, not a static tool flag: git status passes, a Bash command that writes files does not, and a command flagged with injection risk is never treated as read-only.
  • ④ Tool check_permissions: the tool inspects the invocation and returns ALLOW, DENY, ASK, or PASSTHROUGH. A safety ASK (bypass_immune=True) cannot be silenced by allow rules in ⑤; a regular ASK can. Working-directory auto-allow for edits happens here.
  • ⑥ Fallback: the mode’s default when nothing above decided, which gives each mode its personality: prompt (DEFAULT / ACCEPT_EDITS), refuse (EXPLORE / DONT_ASK), or trust (BYPASS).
See Permission Mode for each mode’s full decision flowchart, and the safety check contract for the exact per-mode handling of safety ASKs.

Common Scenarios

The following examples show how to configure AgentState.permission_context for common deployment scenarios. Each recipe combines a mode with rules to match a specific use case.

Next Steps

Permission Mode

Pick a global policy and see each mode’s full decision flow.

Permission Rule

Write allow/deny/ask patterns and accept suggested rules at runtime.

Tool-Level Checks

Read-only detection, dangerous paths, and custom safety checks.

Tool

The toolkit that registers the tools these permissions govern.