Workflows

Test a provider endpoint with curl before wiring it into an agent

AgentArmor teamUpdated Oct 26, 20262 min read

You will check whether each approval rule holds for chained commands, blocked commands, and new sessions before you depend on it. Approval behavior varies across tools, so testing first helps you avoid surprise prompts and unexpected runs.

Write allow rulesKeep them narrower than Bash(*)
Test chained commandNote whether a prompt appears
Test a blocked commandConfirm deny rules still apply
Test in a fresh sessionCheck that "always" choices persisted
Re-test after updatesRepeat the checks whenever the tool changes

Why it matters

Approval settings do not always behave the way they look. Claude Code still prompts on chained Bash commands (opens external site) even when each part is on the allow list. In Roo Code, the "Always allow" checkbox resets after Approve (opens external site), so every MCP call asks again. Test each rule yourself in the version you run.

Steps

Write down the allow rules you plan to use, such as Bash(git:*) and Bash(cd:*). Keep them narrower than Bash(*).
Run a chained command made only of allowed parts, joined with &&, ||, ;, or a pipe. Note whether a prompt appears.
Run a command your deny rule should block, such as a force push matched by Bash(git push --force *). Confirm it is refused.
If you use a community hook for compound commands, test it against your deny rules. A hook that reads only allow patterns can bypass deny rules (opens external site), so repeat the deny cases after any change.
In Gemini CLI, treat the -yolo flag as all-or-nothing. It skips every approval prompt for that session (opens external site), including for destructive commands, so reserve it for disposable work.
Choose "always" at a prompt, then open a fresh terminal session. Gemini CLI's "always" choice applied only to the terminal session where it was made, and new sessions prompted again (opens external site).
For Roo Code MCP tools, approve once with "Always allow" checked, then confirm the next prompt for the same tool does not appear. MCP server settings checkboxes write to ~/.roo/mcp.json immediately, while the chat checkbox did not update that file (opens external site), so do not assume the chat choice is saved.

Common mistakes

Judging a whole chained command by one segment. Test the combined command, since prompts can appear even when each part is allowed.
Using -yolo to avoid prompts. It removes every confirmation, including for destructive commands.
Trusting an "always allow" choice without checking it in a fresh session.
Adding bash, sh, or zsh to the allow list. The hook author warns that bash -c arguments are not checked on the fast path (opens external site).

Checklist

0 of 8 done

Allow rules are narrower than Bash(*)
Chained command made of allowed parts tested for prompts
Deny rule tested with a command it should block
Community hooks retested against deny rules after changes
"Always" choice tested in a fresh session
Roo Code MCP approval confirmed on the next prompt
Gemini -yolo reserved for disposable work
bash, sh, and zsh kept off the allow list

Sources

Was this guide useful?