Approvals & permissions

How nala gates risky actions: spawn proposals, risk tiers, permission modes, and what YOLO really turns off.

nala's safety model is simple to state: agents propose, you dispose. Anything that creates new agents or runs dangerous operations passes through a single approval queue in the daemon, and nothing bypasses it unless you explicitly turn the gate off.

The spawn proposal lifecycle

No agent can mint another agent process. Ever. The path is deliberately indirect:

An agent or planner calls nala_spawn_propose with the launch spec. This writes data only; nothing launches.
You approve a specific proposal version and hash in the approval queue.
Redeem is single-use: it returns the launch argv (including YOLO flags when enabled) exactly once.

There is no path from "agent wants a helper" to "new agent process" that skips your grant.

Risk tiers

Approvals are risk-rated so the queue stays quiet about boring things and loud about dangerous ones:

Tier	Examples	Default
safe	Reading state, listing tasks, drafting artifacts	No approval needed
review	Edits, handoffs, messages to other agents	Queued for one-click approval
critical	Spawning agents, dangerous shell operations	Explicit signature required

Shell execution for the nala agent itself runs under permission modes: supervised (ask for everything), auto_edits (edits flow, the rest asks), full_access (no per-action prompts; required before YOLO flags can apply).

YOLO mode

YOLO is the one big red switch, and it is honest about what it does:

One global control in the status bar, never a per-agent switch.
Each provider's YOLO flags inject only when YOLO is on and full access is active for that agent.
With YOLO on, agent-to-agent execute requests and spawn proposals approve automatically. nala never interrupts you.

Use it when you trust the room: a well-prompted company on a well-scoped mission, in worktrees you can diff afterwards. Keep it off when the fleet is exploring, because every approval in the queue is a chance to read what the agents are about to do before they do it.

First-party MCP trust

The bundled MCP server is recognized by name and granted a scoped method allowlist, but this is not a blanket bypass:

Recognized clients (like claude-code and the Codex MCP client) may call exactly the RPC methods the bundled server invokes, nothing more.
Methods outside the set fall through to normal enforcement.
An explicit user denied always wins.

The threat model is best-effort same-user attribution, not a security boundary against same-user code. If a process on your machine is hostile, the approval queue is the last checkpoint, not the first.

Reading the queue

Approvals arrive in the desktop's approval panel and the TUI's permission dialogs. Nothing in the queue executes while it waits, and every decision lands in the activity journal, so "who signed off on that spawn?" is always answerable with nala trace or the trace panel.