A denial is a feature, not a bug
When the agent reports “permission denied”, the policy did its job: it stopped an action that was not explicitly allowed. The fix is not to open everything — it is to grant exactly the one thing the task needs.
Read the denial
The message names the tool, the target, and the rule that blocked it. In the console the live logs show the same event with context. Decide from that, not from the agent’s summary — agents are good at proposing, not at judging risk.
Decide, then grant narrowly
- Is this action required for the task? If not, tell the agent to work around it.
- Grant the smallest scope: one command, one path, one directory — see shell allowlists and file path rules.
- Re-run the task and confirm only the granted action happened.
- If the task no longer needs it, remove the grant — secure mode best practices in one sentence.
When denials keep coming
Repeated denials mean the task and the policy disagree — one of them is wrong. Re-read the task: an agent that keeps reaching for disallowed tools is often a prompt problem. The capabilities guide covers building a profile that matches the work you actually do.