Permission modes & rules

Nexrall Code decides what runs automatically and what needs your approval through a combination of modes (the session's overall posture) and rules (allow / ask / deny patterns that match specific tools and arguments).

Modes

The mode sets how eager the agent is to act without asking:

Mode	Behavior
Auto	The agent edits files and runs commands directly, prompting only for risky or unapproved actions.
Ask	The agent answers questions and explains code without editing or running anything.
Edit	Edits are permitted; still asks before running commands.
Plan	The agent proposes an approach without writing any files — every write-capable tool is hard-blocked, not just discouraged by instruction.

Switch modes with /mode in a session, or in VS Code from the chat panel.

Rules

Rules are the fine-grained control. Each rule matches a tool and, optionally, a specific invocation, and says what to do:

• allow — run without prompting.
• ask — ask for confirmation first.
• deny — refuse outright.

Rules live in settings.json under permissions, and merge across tiers (managed → user → project) with one hard rule: deny always wins, then allow, then ask.

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "ask": [
      "Bash(curl *)"
    ],
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)"
    ]
  }
}

Rule syntax

• Bare tool name — matches every invocation: "Read" matches all reads.
• Scoped with (pattern) — matches only invocations whose argument matches the pattern: Bash(npm run test *) allows test runs but not other npm run commands.
• * wildcard — matches anything within the scoped pattern.

Built-in safety guardrails

Independent of your rules, Nexrall Code hard-blocks or double-checks a few classes of action:

• Destructive commands — irreversible operations (force-push, drop table, terraform destroy) require explicit confirmation even if they'd otherwise match an allow rule.
• Silent code loss — an edit that drops existing code behind a placeholder like // rest unchanged is refused.
• Test-integrity — weakening a test to make it pass (deleting an assertion, adding .skip) is flagged, not silently accepted.

In headless mode (scripts, CI — where there's no one to confirm), destructive operations are blocked by default; set NEXRALL_ALLOW_DESTRUCTIVE=1 only in a trusted context. See Environment variables.

Headless / CI

nex --output-format json "…" implies auto-approve (there's no one to prompt), but the destructive-command guard still holds unless explicitly relaxed. See Nexrall CLI → Safety in headless mode.

Next steps

• Configuration — where rules live and how tiers merge.
• Environment variables — the safety toggles (NEXRALL_ALLOW_DESTRUCTIVE, NEXRALL_SECURITY_LINT, …).