Permission policy
A permission policy decides which tool calls a machine’s agent is allowed to
make, and you set it on the machine that does the work — it is never fleet-wide.
Start deny-by-default with cmdop permissions mode strict, then add the
narrowest rule each tested task needs. Know the scope before you rely on it: the
rules cover remote tool calls and outbound MCP tools, not local interactive chat.
Cmdop’s permission rules decide which tool calls a machine’s agent is allowed to make. Apply the policy on the machine that will perform the work — it is that machine’s policy, not a fleet-wide one.
What the gate covers
Being precise about the scope matters more here than anywhere else in the docs, because a rule that does not apply to a path is worse than no rule at all.
| Path | Covered by these rules? |
|---|---|
| Tool calls made on behalf of a remote caller | Yes — this is the gate’s main job. |
| Outbound MCP tools the agent invokes | Yes. |
| Local interactive chat on the machine itself | No — it deliberately bypasses this policy and uses a separate built-in gate that blocks high-risk shell commands. |
| An inbound delegated agent run (another operator asking this machine’s agent) | Not yet. That path runs against the same built-in high-risk gate, not against your rules. |
So strict mode is not a switch that stops every possible request arriving from
another operator. It
governs the paths above. Treat the permission policy as one layer of host
security alongside OS accounts, filesystem permissions, and network controls —
never as a replacement for them.
Start with a deny-by-default posture
cmdop permissions mode strict
cmdop permissions allow 'execute_command(git status)'
cmdop permissions listIn strict mode, a covered request with no matching rule is denied. Add only
the smallest rule a task needs, attach a reason so a later reviewer understands
it, and retest the exact operation:
cmdop permissions allow 'execute_command(git status)' \
--reason 'Read repository status'A running agent picks up rule changes without a restart. Confirm the effective
list after every change with cmdop permissions list.
The protected floor
Some actions are denied unconditionally and cannot be re-enabled by a rule
or by any mode, including bypass. Reading private key material under ~/.ssh,
reading .env files, and rm -rf / are examples of what sits on that floor.
If a denial comes from the floor, the fix is to change the task, not the policy.
Choose an action deliberately
| Action | Use it when |
|---|---|
allow | A narrowly matched action is expected and reviewed. |
ask | A present operator should decide each matching request. |
deny | The matching action must remain blocked explicitly. |
Rules are evaluated as deny > ask > allow, so an explicit deny always wins over a broad allow. Do not widen an allow rule to repair one denial — inspect the decision first, then add or revoke the exact rule.
The three rule forms, precedence, and how to scope a rule narrowly.
ModesWhat strict, default, and bypass do with an unmatched request.
Classify a denial before you change policy.
Audit decisionsReview what was allowed, asked, or denied, and why.
Common questions
What do Cmdop permissions control?
They control covered tool calls made by a machine’s agent, including remote tool calls and outbound MCP tools. They do not decide who can connect to the machine, and they do not replace OS users, filesystem permissions, or network policy.
Should I use strict mode on a server?
Yes for unattended or important machines. strict denies covered requests that
match no rule, so you can add the narrowest tested allows instead of relying on
prompts nobody may answer.
Do permission rules apply fleet-wide?
No. A permission policy belongs to the machine that does the work. Configure and audit rules on the target machine, not on a separate fleet-wide object.
Cmdop