Permissions and app tools

Modes

Every conversation has a mode, and each message runs under it:

Each provider enforces the mode for its own tools, such as shell commands and file edits, from settings OpenOrc passes to that process only; your own configuration files are not changed. The exact flags are on Agent providers. Claude Code follows the table above. OpenCode runs only in Plan and Autonomous, because this integration cannot yet guarantee that it asks before every command.

Codex enforces the modes with its own sandbox instead of asking before every command, and the app shows them under Codex's names:

OpenOrc's own tools follow the same rules for every provider; see Actions and each mode.

A mode change applies from your next message, with one exception: switching to Autonomous takes effect at once. OpenOrc approves the requests already waiting, and any the running agent makes after that, apart from typing into a password field.

Approvals

When a provider or OpenOrc needs your permission, the conversation shows a card with the request and three choices: Allow, Allow for this run, and Deny. The agent waits until you answer. In Plan mode, OpenOrc denies a provider's external requests without asking; in Autonomous, it allows them. Questions an agent asks you, such as ask_user, always wait for your answer, in every mode.

Pending approvals live in the core's memory. Quitting OpenOrc denies them, and they are not restored at the next launch.

The audit log records the agent requests OpenOrc decides without asking you, such as those it refuses in Plan or allows in Autonomous, and why. It does not record uses of OpenOrc's own tools that the mode allows, such as memory_record in Accept edits, or repeats covered by "Allow for this run".

Source: packages/core/src/services/run-approvals.ts (awaitApproval, authorizeAppAction)

OpenOrc's own tools

Agents reach OpenOrc's tools, such as task_create, thread_send, browser, and memory_record, through OpenOrc's MCP server. Each agent process gets its own server name and address, and the provider is told not to ask about those tools itself:

Claude Code   --allowedTools mcp__<server>__<tool> …
              --permission-prompt-tool mcp__<server>__approve
Codex         session config: mcp_servers.<server>.tools.<tool>.approval_mode = "approve"
OpenCode      Plan agent rule: { action: "<server>_<tool>", resource: "*", effect: "allow" }

A server of yours that is also named openorc, or that copies a tool name, gets none of this; only the name and address OpenOrc made for that process count.

Not asking at the provider does not mean allowed. OpenOrc applies the conversation's mode when one of its tools runs, the same way for every provider. The tools fall into three groups:

• Reads run in every mode: task_list, task_get, thread_list, thread_read, memory_search, task_context, execution_context, and the browser's open, snapshot, screenshot, and scroll.
• Documents run in every mode, because they change only OpenOrc's own task records and plans: task_create in the backlog, task_update, and plan_write. task_start requires Act, and ask_user waits for you.
• Actions reach beyond the conversation, so they follow the rules below.

execution_switch, available to Slack requests, changes a request's model, effort or folder among the ones your Slack settings allow, never its permissions, so it runs in every mode. Team tools follow the team preview's own rules.

Source: packages/core/src/services/app-actions.ts, packages/core/src/mcp-host/

Actions and each mode

A blocked action returns a message to the agent that says so, and nothing happens. "Allow for this run" on one of these approvals covers later actions of the same kind for the rest of that run, except password fields, which ask every time. Memory has further rules, such as protecting the memories you wrote; see Memory tools.

The browser Preview

The Preview beside a conversation is a real Chromium view with one storage shared by every conversation and kept between launches, so it carries the sessions you signed in to there. An agent that clicks or types in it acts with those sessions, which is why input follows the rules above.

A fill aimed at a password field never reaches the page on its own. The page script refuses it, OpenOrc asks you with the site's name, and only then sends the text again, marked as allowed. Agents cannot mark it themselves. Snapshots never include the value of a password field.

Source: apps/desktop/src/main/browser-page.ts, browser-pane.ts

Messages to other conversations

A conversation that receives a message acts on it with its own mode. A message to a conversation in the same mode or a stricter one is always delivered, because it cannot do anything the sender could not. A message to a more permissive one asks you first, and from Plan it is refused. Messages to a team conversation skip this check: they are queued for its lead in every mode. How messages travel, the limit on chains of agent messages, and retries are covered in Messages between conversations.