Skip to content

Permissions & approvals

agent_permission controls whether mistral.rs may run an agent action after the model asks for one. It applies to all server-executed actions, not just Python: code execution, shell, web search, file tools, registered callbacks, and external tool dispatch.

Terminal window
mistralrs run --agent -m google/gemma-4-E4B-it --agent-permission ask

| Mode | Behavior | |---|---| | auto | Run the action as soon as the tool call is valid. | | ask | Pause before the action and ask the app, callback, or CLI user to approve it. | | deny | Keep the tool visible to the model, but return a denied tool result instead of running it. |

A request can only tighten the permission mode, never loosen it. The server or runner policy is a floor: a request can go from auto to ask or deny, but cannot loosen a server started with --agent-permission ask or --agent-permission deny.

code_execution_permission and --code-exec-permission are compatibility aliases for code-execution-focused apps; prefer agent_permission for new code.

Permissioning is separate from sandboxing. Permission mode decides whether an action may start; the sandbox controls what generated code and shell commands can access after they start.

All five surfaces (CLI, built-in UI, HTTP, Python, Rust) expose the same approval semantics:

| Concept | Meaning | |---|---| | Approve or deny | Allow the action, or return a denied tool result to the model. | | message | Optional deny message returned to the model as the tool result. | | remember_for_session | On approve, skip later approval prompts for the same session_id. |

In interactive mode, ask prompts inline before each agent action. Choosing always approves later actions in the same CLI session.

Terminal window
mistralrs run --agent -m google/gemma-4-E4B-it --agent-permission ask

deny is useful when you want to inspect proposed actions without letting them run:

Terminal window
mistralrs run --agent -m google/gemma-4-E4B-it --agent-permission deny