Permissions
Cmdop permissions are a rule-based gate deciding what may be done on a machine, as distinct from who may be present in a session. Each gated tool call is matched against ordered allow, ask, and deny rules, deny taking precedence over ask over allow, plus a built-in floor of high-risk targets no rule can reopen. Three modes decide unmatched calls.
Permissions decide what may be done on a machine, as opposed to who may be present in a session. They are the boundary you configure before letting automation run somewhere that matters.
The model
Every gated tool call is matched against an ordered set of rules. A rule names a whole tool, or a tool and an argument pattern:
cmdop permissions allow 'execute_command(git *)'
cmdop permissions ask 'file_write(/app/**)'
cmdop permissions deny 'execute_command(rm *)'
cmdop permissions revoke 'execute_command(git *)'- allow — runs without prompting.
- ask — prompts at call time.
- deny — always blocked.
Precedence is deny over ask over allow, so adding a broad allow can never
quietly reopen something a deny closed. A built-in floor of high-risk targets
is always denied and cannot be overridden by a rule you write.
The three modes
The mode decides what happens to a call that matches no rule at all:
| Mode | Unmatched call |
|---|---|
default | Prompts you, and denies if nobody answers |
strict | Denied |
bypass | Allowed, except the built-in floor |
cmdop permissions mode # show the current mode
cmdop permissions mode strictStart an unattended host in strict and add narrow rules only after testing the
work it actually needs. bypass is deliberately awkward to enable and should
not be a standing configuration.
What the gate covers
This policy governs daemon-owned tool activity — the remote tool-manager calls and outbound MCP tools that run without a person watching.
Two paths deliberately do not go through it, and knowing which is the difference between a correct threat model and a false sense of coverage:
- Local interactive chat uses its own danger gate, because you are present and answering.
- Inbound requests from another machine run under the built-in danger gate that blocks high-risk shell commands, not under your configured rule set. Do not treat these rules as a per-caller policy for delegated agent work.
Permissions are also not a substitute for operating-system accounts, filesystem permissions, or normal host hardening. They constrain Cmdop’s own tool activity.
Reviewing decisions
cmdop permissions list # rules and the current mode
cmdop permissions audit # recent permission decisionsCommon questions
Do permissions decide who can connect to a machine?
No. Permissions decide what Cmdop tool activity may do on a machine. Presence and access are separate: relay authentication, fleet membership, and a connection PIN decide who may reach or drive a machine.
What mode should I use for an unattended server?
Start in strict, where unmatched calls are denied, then add narrow rules only
after testing the work the server actually needs. Avoid leaving bypass as a
standing configuration on machines that matter.
Do permissions cover external MCP tools?
They cover the Cmdop-owned tool activity that reaches the machine, but an external MCP server remains its own trust boundary. Review and approve the exact tool catalogue, and secure any network-reachable MCP server before using it.
Cmdop