Permissions

Control tool access per agent or globally in neusiscode.json:

{
  "permission": {
    "*": "ask",
    "bash": {
      "*": "ask",
      "git status": "allow",
      "rm *": "deny"
    },
    "edit": {
      "*": "deny",
      "src/**": "allow"
    },
    "skill": {
      "*": "allow",
      "internal-*": "deny"
    }
  }
}

Values

Value	Behaviour
"allow"	Run without prompting
"ask"	Prompt the user for approval
"deny"	Blocked entirely

Permission keys

Each key under permission targets one tool (or tool class). Most keys accept either a single value ("allow" / "ask" / "deny", applied to everything) or an object of pattern: value rules. A bare string is shorthand for { "*": <value> }.

Key	Targets	Form
read	File reads (matched against the file path)	value or rules
edit	File edits via edit / write / apply_patch	value or rules
glob	Glob searches	value or rules
grep	Content searches (matched against the search query)	value or rules
list	Directory listings	value or rules
bash	Shell commands (matched against the command)	value or rules
task	Spawning subagents via the task tool	value or rules
external_directory	Access to paths outside the worktree	value or rules
todowrite	The todowrite tool	value only
question	The question tool	value only
webfetch	The webfetch tool	value only
websearch	The websearch tool	value only
skill	Skill invocations	value or rules
lsp	LSP tool	value or rules

Unknown keys are accepted too, so custom tools can be gated the same way.

:::note Rule precedence is order-sensitive Within an object, rules are evaluated in the order you write them — your key order is preserved when the config is parsed. Put the broad fallback ("*") first and narrower overrides after it. :::

Fewer prompts by default

Out of the box the primary build agent grants tools with "*": "allow", so routine work — running shell commands, updating the todo list, and spawning subagents with the task tool — runs without a prompt. You opt into prompting by setting a key to "ask", or block a tool with "deny".

Because todowrite is a plain on/off permission (it has no patterns to match), it resolves straight to the configured value. With the default "allow" it never interrupts a session.

{
  "permission": {
    "todowrite": "allow",
    "task": "allow",
    "bash": {
      "*": "allow",
      "rm -rf *": "deny"
    }
  }
}

:::info Subagents are stricter than the parent When the task tool spawns a subagent, that subagent does not inherit todowrite or task unless its own ruleset explicitly permits them — both default to deny for subagents. This keeps spawned agents focused and avoids recursive task-spawning prompts. :::

Worktree-relative path matching

For tools that act on a file path — read, edit, write, and apply_patch — permission patterns are matched against the path relative to your worktree root, not the absolute path. This means a pattern like src/** matches <worktree>/src/... regardless of where the worktree lives on disk.

read uses the same worktree-relative basis as edit / write / apply_patch, so a single set of path patterns applies consistently across all of them:

{
  "permission": {
    "read": {
      "*": "allow",
      "*.env": "ask"
    },
    "edit": {
      "*": "deny",
      "src/**": "allow",
      "docs/**": "allow"
    }
  }
}

In this example edit is denied everywhere except the worktree-relative src/** and docs/** trees, and reads prompt only for .env files.

note

grep patterns are matched against the search query, not file paths — for example "grep": { "*": "allow", "password": "ask" } gates by what you search for. Restricting where searches and reads may reach on disk is handled by the external_directory key, which gates access to paths outside the worktree.

Default read protections

The default ruleset prompts before reading dotenv-style secret files even when read is otherwise allowed:

Pattern	Default
* (everything)	allow
*.env	ask
*.env.*	ask
*.env.example	allow

You can override these in your own permission.read rules.

Plan Mode

The built-in plan agent disallows all edit tools — edit, write, and apply_patch resolve to deny. A subagent spawned from Plan Mode inherits the parent agent's edit-deny rules, so it stays read-only too; it cannot bypass the restriction by acting through the task tool.

caution

The edit-deny restriction in Plan Mode lives on the agent's ruleset. A subagent launched from Plan Mode propagates the parent agent's deny rules (not just the parent session's), so edits remain blocked all the way down. Both the general and explore subagents stay read-only when launched from Plan Mode.

Path helpers

Patterns understand a few home-directory shorthands, expanded before matching:

Prefix	Expands to
~/	your home dir
~	your home dir
$HOME/	your home dir
$HOME	your home dir