Tool permission policies

In Agent mode, every tool call passes through Mogick's permission gateway. For runtime policy switching, approval-card actions, and execution behavior, see Tool approvals and permission policies. This page defines each policy and the per-tool settings available in config.json.

Four permission policies

Permission policies determine which tool calls run automatically, require confirmation, or are denied.

Policy	Read-Only Tools	File Writing	Shell	Git Modification	MCP	Approval
read	Auto-approve	By tool configuration	By tool configuration	By tool configuration	Read-only prompts can be auto-approved	Safe built-in status tools can also be auto-approved
workspace	Auto-approve	Auto-approve non-deleting writes in the workspace	By tool configuration	By tool configuration	By tool configuration	Confirmation for operations outside the workspace or deletions
auto	Auto-approve	Auto-approve non-deleting writes in the workspace	According to fallback gate	According to fallback gate	According to fallback gate	For other calls, see _mogick_ask_permission
yolo	Auto-approve	Auto-approve	Auto-approve	Auto-approve	Auto-approve	Explicit deny still rejects

read automatically allows read-only tools and safe tools that modify only Mogick's internal session state, such as todo, plan, and question tools. It does not simply deny every non-read operation; other calls still follow their per-tool allow, ask, or deny setting.

workspace automatically allows non-deleting file.write and file.edit calls inside the workspace. Writes outside the workspace, shell commands, unknown tools, and deletion operations still require confirmation. The workspace defaults to the current Git repository root, or the current working directory when outside a repository.

auto is the default. It automatically allows read-only tools, safe built-in tools, and non-deleting workspace writes. Other calls use _mogick_ask_permission as the fallback gate.

yolo automatically allows calls that would otherwise require confirmation. The TUI displays a red status badge, and tools explicitly configured as deny remain unavailable.

Under non-yolo policies, file.delete, file.edit containing delete patches, and shell.exec matching delete commands always request confirmation.

Follow the principle of least privilege: begin with read or workspace, then switch temporarily only when the task requires broader access.

Configuration

Permission control has two layers. --tool-call-permissions and TUI /permissions select the current session policy. The agents section of config.json controls whether each tool is registered and its default permission in each mode. Both layers contribute to the final decision.

config.json

Use agents.<mode>.tools.<tool> for fine-grained control over individual tools:

{
  "agents": {
    "agent": {
      "tools": {
        "shell.exec": {
          "enabled": true,
          "permission": "ask"
        }
      }
    }
  }
}

Field	Type	Value	Description
agents.<type>.tools.<tool>.enabled	bool	true / false	Whether to register the semantic tool; if omitted, inherit preset
agents.<type>.tools.<tool>.permission	string	allow / ask / deny	Execution permission; if omitted, inherit preset

agents is resolved by configuration layer. A project entry for the same agent type and tool replaces the global tool entry. Tools not declared by the project fall back first to the global entry and then to the mode preset. Deletion safeguards and the session-level CLI policy still apply.

Plan mode

Plan mode operates independently of permission policies. Regardless of whether the outer policy is set to auto or yolo, this mode does not allow file writes, shell, MCP, or other network operations. After entering Agent mode, the permission policy is restored to the current configuration level.

Subagent permission boundaries

A subagent can never have broader permissions than its parent session. The runtime combines the parent's callable tools, the subagent descriptor's allowedTools, deniedTools, and readOnly constraints, and the final gateway check. Built-in subagents focus on read-only exploration and review; they cannot write files, run shell commands, or create nested subagents.

read, workspace, auto, and yolo are parent-session policies, not subagent descriptor values. Even when the parent uses yolo, each subagent remains subject to its own descriptor and the permission gateway. Subagents also have independent step and tool-call budgets and stop when either limit is reached.

Related documents

• Tool Approval and Permissions Policy — Runtime policy switching, approval card and execution process
• List of built-in tools
• Subagents