The permission gate

The board runs agents that execute shell commands and edit files on your machine, so every tool and command an agent reaches for is checked against a permission gate before it runs. Anything outside the agent’s pre-approved set pauses the run and parks the ticket in Pending Action until a human answers; Approve a tool request walks through that, and Permission lists lists what the gate checks against.

A new MCP server gets no free pass: its first call routes through the same panel as any other new tool.

Some commands always ask. Recursive deletion, sudo, git push, piping a download into a shell and the rest of the built-in dangerous list go to a human even under the default command policy, and the built-in safe baseline never approves one. Only a grant you give yourself (an Always allow on the panel, or Allow under Settings > Security > Command permissions) lets one through, and a Deny entry beats everything. The full order is in Permission lists.

Which engines it holds on

The gate needs an approval channel: a way for the engine to stop before a tool runs and wait for the board’s answer. Not every engine has one.

Engine	Gated	Why
Claude Code	Yes	Every tool call goes through the board’s approval callback.
Codex (the default app-server transport)	Yes	The transport has an approval channel, so a Codex run gets the same panels and grants as a Claude run. Codex is handed whole MCP servers, so a deny entry that bans one tool on a server does not hold; ban the whole server (mcp__<name>__*) instead.
Codex with REV0_CODEX_TRANSPORT=exec	No	The older exec transport has no approval channel. Its sandbox still follows the run (read only for a plan), but no command reaches the board first. It is an escape hatch, not a mode to run in.
Cursor	No	Cursor’s print mode has no approval callback. The board runs it with --force inside Cursor’s own sandbox (read only --mode ask for a plan run), so Cursor’s sandbox and project permissions apply, but the board never sees a command before it runs.

The run itself says so: when a rule is not in force, the board posts an Engine parity comment on the ticket at the start of the run naming it. Give those engines only work you would let run unattended, in a repo you can reset. Run Codex instead of Claude Code covers both engines.

What an approved command can read

The gate decides which command runs. It does not decide what that command can read: by default every process an agent spawns inherits the board’s own environment, which includes REV0_AUTH_TOKEN (the board’s API token, exactly what would let a command go around the gated tools), your Jira and Slack tokens, and SSH_AUTH_SOCK (signing with your SSH keys without ever seeing a private key).

Allow-list the agent’s environment (Settings > Automation > Features) turns that around: the child environment is built from an allow-list instead of inherited. Agents keep PATH, HOME, the temp, locale and timezone variables, TLS and proxy settings, the VIRTUAL_ENV and UV_* venv pins and the engine’s own credential; everything else is dropped. The board’s kanban MCP tools are unaffected, because that server has always been handed its token explicitly rather than inheriting one.

It is off by default on purpose: an integration on your machine may legitimately read an inherited variable, and stripping it silently is miserable to diagnose. Notable casualties once you turn it on are SSH_AUTH_SOCK (an agent pushing over SSH), GH_TOKEN and GITHUB_TOKEN (an agent shelling out to gh, whose own login still works) and any cloud credential (AWS_*, GOOGLE_*). Name the ones you need in Extra variables to pass through. This is a second, independent layer: it changes nothing about the gate itself.

What the gate does not cover

The gate governs agents. It does not protect a board that anyone on the network can reach: whoever reaches an unauthenticated port can create tickets and approve requests themselves. That is what the access token is for; see Security.