Permission Patterns

Permission patterns give fine-grained control by matching a tool’s argument (a command string, a file path) against a glob and mapping it to an action.

Format

A permission entry is either a single action, or a map of glob → action. There is no Tool(pattern) syntax and no allow/deny arrays — the tool key groups its patterns:

{
  "permission": {
    "bash": {
      "*": "ask",
      "ls *": "allow",
      "git status": "allow",
      "rm -rf *": "deny"
    },
    "edit": {
      "reports/**": "allow",
      ".env*": "deny"
    }
  }
}

The glob matches the tool’s argument: for bash it’s the command string, for edit/read it’s the file path.

Wildcards

Only two wildcards are supported:

A pattern that ends in a space + * also matches the bare command with no arguments — so "ls *" matches both ls and ls -la.

Precedence

When several patterns match, the more specific (longer) pattern wins. Patterns are evaluated shortest-first, and the last match applies — so a broad "*": "ask" can be overridden by a longer "git status": "allow":

{
  "permission": {
    "bash": {
      "*": "ask",
      "npm *": "allow",
      "npm publish*": "deny"
    }
  }
}

Here npm test is allowed, but npm publish is denied.

Examples

Allow a toolchain, block the dangerous parts

{
  "permission": {
    "bash": {
      "*": "ask",
      "git *": "allow",
      "git push*": "ask",
      "rm -rf *": "deny"
    }
  }
}

Restrict edits to a directory

{
  "permission": {
    "edit": {
      "*": "deny",
      "src/**": "allow",
      "src/secrets/**": "deny"
    }
  }
}

Related Documentation

• Permissions Overview - The permission model and keys
• Automation - Non-interactive / CI permissions
• Configuration - Where permissions live in config