Skip to main content
Permission modes control how Pioneer handles tool actions during a turn. They apply to file access, commands, MCP tools, skills, web access, computer control, and subagent launches. The selected mode also resolves a sandbox policy for the turn. Pioneer records that policy and uses it to check filesystem roots, network access, process execution, scoped approvals, and audit events. Choose the mode in the composer before sending a turn. The selected mode applies to that turn and is recorded in the turn history.

​
The three modes

If you are unsure which mode to use, start with Supervised.

​
What a prompt looks like

If a tool action needs approval, Pioneer opens a request in the app. You can allow it once, allow the same kind of action for the rest of the turn, deny it, or cancel it. Use allow once when you want to inspect each action. Use allow for turn when the request is clearly part of the current task and you do not want repeated prompts for the same action scope. If you deny a request, the agent should continue with allowed alternatives or explain what it could not do.

​
Gateway boundary

Permission modes do not move execution to another machine or OS account. They constrain work inside the gateway environment:
  • a local gateway runs tools on your computer;
  • a remote gateway runs tools on the remote machine;
  • a scheduled task runs on the gateway even if your desktop app is closed.
Use a separate gateway when the work needs a different machine, filesystem, account, network, or set of credentials. Within a gateway, use permission modes and scoped approvals to control a turn.

​
Good defaults

Use Supervised for:
  • first runs in a new project;
  • unfamiliar skills or MCP servers;
  • remote gateways;
  • prompts that may run commands;
  • scheduled or task-backed work before you trust it.
Use Auto-accept edits for:
  • known repositories where file edits are expected;
  • code cleanup or documentation edits where you still want command/network prompts;
  • workflows where reviewing every patch prompt is too noisy.
Use Full access for:
  • trusted local projects;
  • throwaway environments;
  • repeatable workflows whose tool behavior you already reviewed.

​
Further reading

  • Quick Start shows a first supervised thread.
  • Workspace & Organization explains when to use workspaces versus separate gateways.
  • Permission System explains the implementation: profiles, security snapshots, sandbox policy, approval requests, audit events, and task permission caps.