Skip to main content
0x0 uses a rule-based permission system that controls which tools agents can invoke and under what conditions.

​
Actions

Every permission rule resolves to one of three actions:
ActionBehavior
allowTool executes immediately without prompting
denyTool call is rejected automatically
askUser is prompted to approve or reject the call

​
Rule structure

A rule consists of three fields:
  • permission — the permission name (e.g., read, edit, bash)
  • pattern — a glob pattern matched against the tool’s target (e.g., file path, command)
  • action — allow, deny, or ask
Rules are evaluated using last-match-wins semantics. If no rule matches, the default is ask.

​
Permission names

PermissionApplies toDescription
readread toolFile read operations
editedit, write, apply_patch, multieditFile write and edit operations
searchsearch toolFile search (content grep and file glob)
search_remotesearch_remote, websearch, webfetch, codesearchWeb search and URL fetch
bashbash toolShell command execution
tasktask toolSubtask creation / agent delegation
external_directoryexternal-directory toolAccess to directories outside the project
todowritetodowrite toolWriting TODO items
todoread(internal)Reading TODO items
questionquestion toolAsking the user interactive questions
lsplsp toolLanguage Server Protocol operations
doom_loop(internal)Doom loop detection (repeated failing tool calls)
skillskill toolSkill execution

​
EDIT_TOOLS mapping

The tools edit, write, apply_patch, and multiedit all map to a single edit permission. Configuring edit: deny denies all four tools.

​
Config syntax

Permission rules can be specified in two forms:

​
Flat action

A single action applied to all patterns: 
permission:
  bash: ask
  edit: allow
  read: allow

​
Glob object

An object mapping glob patterns to actions: 
permission:
  read:
    '*': allow
    '*.env': ask
    '*.env.*': ask
    '*.env.example': allow
  edit:
    '*': allow
    '.zeroxzero/memory.md': deny
  bash: ask
Path patterns support ~/ and $HOME/ expansion.

​
Default permissions

The default ruleset applied to native agents (builder, planner): 
permission:
  '*': allow
  doom_loop: ask
  question: deny
  external_directory:
    '*': ask
  read:
    '*': allow
    '*.env': ask
    '*.env.*': ask
    '*.env.example': allow
Custom (non-native) agents start with all permissions denied. Only tools listed in tools_allowed are explicitly allowed, and the agent’s permission field is layered on top.

​
Agent-level overrides

Each agent can define its own permission rules that override the defaults: 
agent:
  plan:
    permission:
      edit:
        .zeroxzero/memory.md: allow
      bash: deny
Rules from agent config are merged on top of the agent’s base permissions using last-match-wins.

​
Ask/reply flow

When a tool call resolves to ask:
  1. A permission request is created and the tool call blocks.
  2. The user sees the request in the TUI and can respond with:
    • Allow once — resolves this single request
    • Allow always — adds a permanent allow rule for this permission and pattern, and auto-resolves any other pending requests now covered
    • Reject — rejects this request and all other pending requests for the session
Plugins can intercept permission requests via the permission.ask hook to auto-allow or auto-deny.

​
Error types

ErrorWhenEffect
DeniedErrorRule evaluates to denyTool call rejected, includes the relevant ruleset
RejectedErrorUser rejects without feedbackHalts the current tool execution
CorrectedErrorUser rejects with a feedback messageContinues with user guidance

​
Inline override

Use ZEROXZERO_PERMISSION to inject permission rules via environment variable: 
ZEROXZERO_PERMISSION='{"bash":"allow","edit":"allow"}' 0x0 run "fix the bug"

​
See also