XibeCode

Permission Rules

Fine-grained allow, deny, and ask rules for controlling tool execution in XibeCode. Configure per-tool patterns via settings.

XibeCode's permission rules system gives you fine-grained control over which tools the agent can use and when it should ask for confirmation. Rules are configured through the settings system and evaluated on every tool call.

Rule Types

There are three rule types, evaluated in order of priority:

  1. Deny — The tool call is blocked immediately
  2. Ask — The agent requests user confirmation before proceeding
  3. Allow — The tool call proceeds automatically

Rules are checked in this order: if a tool matches a deny rule, it is blocked regardless of any allow rules. If it matches an ask rule, the user is prompted. If it matches an allow rule and no deny/ask rules match, it proceeds automatically.

Rule Syntax

Rules use a Tool(pattern) format:

ToolName(pattern)
  • ToolName — The name of the tool (e.g., Bash, Read, Write, Edit)
  • pattern — A glob-like pattern matching the tool's primary argument

Pattern Examples

RuleMeaning
Bash(git *)Allow/deny bash commands starting with git
Bash(pnpm *)Allow/deny bash commands starting with pnpm
Read(*)Allow/deny all file reads
Write(src/**)Allow/deny writes to files under src/
Write(*.test.ts)Allow/deny writes to test files
Bash(rm -rf *)Deny dangerous recursive delete commands
Edit(*)Allow/deny all file edits

Wildcards

  • * matches any sequence of characters within a single path segment
  • ** matches any sequence of characters across path segments
  • * at the end matches any suffix

Configuration

Permission rules are defined in settings files:

{
  "permissions": {
    "allow": [
      "Bash(git *)",
      "Bash(pnpm *)",
      "Read(*)",
      "Write(*)",
      "Edit(*)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl *|*)",
      "Bash(wget *)"
    ],
    "ask": [
      "Bash(*)"
    ]
  }
}

Setting Rules via CLI

# Set allow rules
xc settings set permissions.allow '["Bash(git *)","Read(*)","Write(*)"]'

# Set deny rules
xc settings set permissions.deny '["Bash(rm -rf *)"]'

# Set ask rules
xc settings set permissions.ask '["Bash(*)"]'

Evaluation Flow

When the agent wants to use a tool:

  1. Check deny rules — if any match, the tool call is blocked
  2. Check ask rules — if any match, the user is prompted for confirmation
  3. Check allow rules — if any match, the tool call proceeds
  4. If no rules match — the default policy applies (configurable, typically ask)

Tool-Specific Rules

Bash Rules

Bash rules match against the full command string:

Bash(git commit -m "fix: typo")     → matches Bash(git *)
Bash(rm -rf /)                       → matches Bash(rm -rf *)
Bash(pnpm install)                    → matches Bash(pnpm *)
Bash(npm run build)                   → matches Bash(*) (ask rule)

File Tool Rules

File tools (Read, Write, Edit) match against the file path:

Read(src/agent.ts)       → matches Read(*)
Write(src/utils.ts)      → matches Write(src/**)
Edit(package.json)       → matches Edit(*)
Write(.env)              → matches Write(*) but you might want to deny it

Example Configurations

Permissive (Full Autonomy)

{
  "permissions": {
    "allow": ["Bash(*)", "Read(*)", "Write(*)", "Edit(*)"],
    "deny": ["Bash(rm -rf *)"],
    "ask": []
  }
}

Cautious (Confirm Shell Commands)

{
  "permissions": {
    "allow": ["Read(*)", "Write(src/**)", "Edit(src/**)"],
    "deny": ["Bash(rm -rf *)", "Bash(curl *|*)"],
    "ask": ["Bash(*)", "Write(*)", "Edit(*)"]
  }
}

Read-Only

{
  "permissions": {
    "allow": ["Read(*)"],
    "deny": ["Write(*)", "Edit(*)", "Bash(*)"],
    "ask": []
  }
}

Project-Enforced Policy

In /etc/xibecode/settings.json (policy source, cannot be overridden):

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl *|*)",
      "Bash(wget *)",
      "Write(.env*)"
    ],
    "allow": ["Read(*)", "Write(src/**)", "Edit(src/**)", "Bash(git *)", "Bash(pnpm *)"]
  }
}

Agent Behavior

When a tool call is denied:

  • The agent receives a "Tool call denied by permission rules" message
  • The agent does not retry the denied tool call
  • The agent attempts to accomplish the task using alternative approaches
  • If no alternative exists, the agent reports the denial to the user

When a tool call requires confirmation:

  • The agent pauses and waits for user approval
  • The user can approve or deny the specific call
  • The user can approve all similar calls for the session

Interaction with Agent Modes

Agent modes have built-in tool restrictions that combine with permission rules:

  • Review mode — Read-only by mode definition, regardless of permission rules
  • Security mode — Read-only by mode definition
  • Agent mode — Full access, filtered by permission rules
  • Plan mode — Can only write to implementations.md

Permission rules add a layer on top of mode restrictions. Even in agent mode, denied tools remain denied.

Next Steps

Ctrl+I
Assistant

How can I help?

Ask me about configuration, installation, or specific features.