Debug permission denials

Find out which layer refused a request before you change any policy, because three of the four possible sources are not fixed by editing rules. Run cmdop permissions audit on the target first: if the denial has no audit entry at all, the permission rules never saw the request, and weakening them will not help. Classify the denial, then make the smallest justified change.

1. Inspect the decision on the target

cmdop permissions list
cmdop permissions audit

If no audit decision corresponds to your request, the permission rules never saw it. Either the request failed earlier — machine offline, wrong credential — or it travelled a path the rules do not cover, such as local interactive chat or a delegated agent run (see what the gate covers). Check machine availability, credentials, and agent logs rather than weakening policy that was never consulted.

2. Classify the denial

Remember that deny beats ask beats allow: if you added an allow and still get denied, look for a deny that outranks it before assuming the rule is wrong.

3. Make the smallest justified change

If the task is safe and expected, add a narrowly matched rule with a reason and retest. The running agent picks the change up without a restart:

cmdop permissions allow 'execute_command(git status)' \
  --reason 'Repository status for the deployment check'
cmdop permissions list

For an unattended machine, prefer a specific allow or deny in strict mode over a mode change. If you only need to get past a prompt once, use --approve on that single invocation instead of touching persisted policy — see Permission modes.

Revoke temporary rules when the task is done:

cmdop permissions revoke 'execute_command(git status)'

Never route around a block by weakening host-level protections, and do not assume a remote caller can approve something on the machine’s behalf.

Common questions

Why was a Cmdop command denied?

Start with cmdop permissions audit on the target machine. The denial may come from the protected floor, an explicit deny, a missing rule under the current mode, or a timed-out prompt. Only one of those is solved by adding a narrow allow rule.

Why did adding an allow rule not fix the denial?

deny beats ask, and ask beats allow. If an explicit deny or ask rule matches the same request, it outranks the allow. If no audit entry exists, the permission rules never saw the request.

Should I switch to bypass to debug a denial?

Usually no. For one invocation, prefer the scoped --approve path where it applies. For unattended machines, keep strict and add or revoke narrow rules after reading the audit evidence.