> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/CyberStrikeus/CyberStrike/llms.txt
> Use this file to discover all available pages before exploring further.

# Permissions

> Control which tools CyberStrike can use automatically, which require confirmation, and which are denied.

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:

| Action    | Behavior                                               |
| --------- | ------------------------------------------------------ |
| `"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:

| Target                 | Accepts patterns | Description                                |
| ---------------------- | ---------------- | ------------------------------------------ |
| `read`                 | Yes              | Read files from disk                       |
| `edit`                 | Yes              | Write or modify files                      |
| `glob`                 | Yes              | Search file paths using glob patterns      |
| `grep`                 | Yes              | Search file contents                       |
| `list`                 | Yes              | List directory contents                    |
| `bash`                 | Yes              | Execute shell commands                     |
| `task`                 | Yes              | Spawn sub-tasks or agents                  |
| `external_directory`   | Yes              | Access paths outside the project directory |
| `lsp`                  | Yes              | Use language server protocol features      |
| `skill`                | Yes              | Load and execute skills                    |
| `todowrite`            | No               | Create or update todo items                |
| `todoread`             | No               | Read todo items                            |
| `report_vulnerability` | No               | Report a vulnerability finding             |
| `question`             | No               | Ask clarifying questions                   |
| `webfetch`             | No               | Fetch content from a URL                   |
| `websearch`            | No               | Perform a web search                       |
| `codesearch`           | No               | Search code repositories                   |
| `doom_loop`            | No               | Re-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:

```json cyberstrike.json theme={null}
{
  "permission": {
    "bash": "ask",
    "read": "allow",
    "webfetch": "deny"
  }
}
```

Set all tools at once using `"*"`:

```json cyberstrike.json theme={null}
{
  "permission": "allow"
}
```

This is equivalent to:

```json theme={null}
{
  "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.

```json cyberstrike.json theme={null}
{
  "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.

<Tip>
  Use `"*": "allow"` as the last entry in a pattern object to allow everything that didn't match a more specific rule.
</Tip>

## 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.

```json cyberstrike.json theme={null}
{
  "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):**

```json cyberstrike.json theme={null}
{
  "permission": "allow"
}
```

**Allow reads, ask for writes and commands:**

```json cyberstrike.json theme={null}
{
  "permission": {
    "read": "allow",
    "glob": "allow",
    "grep": "allow",
    "list": "allow",
    "edit": "ask",
    "bash": "ask",
    "webfetch": "ask"
  }
}
```

**Deny bash entirely, allow everything else:**

```json cyberstrike.json theme={null}
{
  "permission": {
    "bash": "deny",
    "*": "allow"
  }
}
```

**Protect secrets, allow other reads:**

```json cyberstrike.json theme={null}
{
  "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:

```bash theme={null}
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.

<Warning>
  The `CYBERSTRIKE_PERMISSION` override does not affect managed (enterprise) config, which always has the highest priority.
</Warning>