Skip to main content
The permissions system lets you specify whether CyberStrike should automatically use a tool, ask you first, or never use it. Permissions can be set globally for all sessions or scoped to a specific agent.

​
Permission actions

Every permission rule resolves to one of three actions:
ActionBehavior
"allow"CyberStrike uses the tool without asking
"ask"CyberStrike pauses and asks for confirmation each time
"deny"CyberStrike refuses to use the tool

​
Permission targets

The permission object maps tool names to actions. The following targets are recognized:
TargetAccepts patternsDescription
readYesRead files from disk
editYesWrite or modify files
globYesSearch file paths using glob patterns
grepYesSearch file contents
listYesList directory contents
bashYesExecute shell commands
taskYesSpawn sub-tasks or agents
external_directoryYesAccess paths outside the project directory
lspYesUse language server protocol features
skillYesLoad and execute skills
todowriteNoCreate or update todo items
todoreadNoRead todo items
report_vulnerabilityNoReport a vulnerability finding
questionNoAsk clarifying questions
webfetchNoFetch content from a URL
websearchNoPerform a web search
codesearchNoSearch code repositories
doom_loopNoRe-enter the agent loop after completing
Any custom tool name from a plugin or MCP server can also be used as a key.

​
Basic syntax

Set a tool to a single action:
cyberstrike.json
{
  "permission": {
    "bash": "ask",
    "read": "allow",
    "webfetch": "deny"
  }
}
Set all tools at once using "*":
cyberstrike.json
{
  "permission": "allow"
}
This is equivalent to: 
{
  "permission": { "*": "allow" }
}

​
Pattern-based rules

For tools that accept patterns (read, edit, glob, grep, list, bash, external_directory, lsp, skill, task), you can provide an object mapping glob patterns to actions instead of a single action string.
cyberstrike.json
{
  "permission": {
    "read": {
      "*.env": "ask",
      "*.key": "deny",
      "*": "allow"
    },
    "edit": {
      "src/**": "allow",
      "*": "ask"
    },
    "external_directory": {
      "/tmp/**": "allow",
      "*": "deny"
    }
  }
}
Rules are evaluated in the order they appear. The first matching pattern wins.
Use "*": "allow" as the last entry in a pattern object to allow everything that didn’t match a more specific rule.

​
Global vs. agent-specific permissions

Permissions set at the top level of cyberstrike.json apply to all agents. You can also set permissions inside an individual agent’s config block to override the global rules for that agent only.
cyberstrike.json
{
  "permission": {
    "bash": "ask",
    "read": "allow"
  },
  "agent": {
    "explore": {
      "permission": {
        "bash": "deny",
        "read": "allow",
        "webfetch": "allow"
      }
    }
  }
}
In this example, the global config asks for bash confirmation, but the explore agent denies bash entirely and additionally allows webfetch without prompting.

​
Common patterns

Allow everything (trust all tools):
cyberstrike.json
{
  "permission": "allow"
}
Allow reads, ask for writes and commands:
cyberstrike.json
{
  "permission": {
    "read": "allow",
    "glob": "allow",
    "grep": "allow",
    "list": "allow",
    "edit": "ask",
    "bash": "ask",
    "webfetch": "ask"
  }
}
Deny bash entirely, allow everything else:
cyberstrike.json
{
  "permission": {
    "bash": "deny",
    "*": "allow"
  }
}
Protect secrets, allow other reads:
cyberstrike.json
{
  "permission": {
    "read": {
      "**/.env": "deny",
      "**/*.key": "deny",
      "**/*.pem": "deny",
      "*": "allow"
    }
  }
}

​
Environment variable override

You can supply or override permissions without modifying any config file by setting the CYBERSTRIKE_PERMISSION environment variable to a JSON-encoded permission object: 
CYBERSTRIKE_PERMISSION='{"bash":"deny","read":"allow"}' cyberstrike
This is merged on top of all file-based permission config, so it takes precedence over both global and project configs.
The CYBERSTRIKE_PERMISSION override does not affect managed (enterprise) config, which always has the highest priority.

Build docs developers (and LLMs) love

Get started for freeTalk to us