How Permissions Are Resolved

Model selection, thinking effort, and permission presets belong to each conversation. Changing a selection affects that chat and sets the default inherited by new chats; other existing conversations keep their values. The permission presets are "Ask every time", "Auto-edit", and "Skip all permissions". In an ordinary running conversation, a permission change applies at the next tool call.

Plan mode is a separate conversation mode, not a fourth permission preset. It requires investigation and discussion without performing the implementation. After plan acceptance, execution still goes through the checks below. Plan documents use a dedicated workflow; they do not create a general exception for project-file writes.

Change the permission preset through the composer dropdown. The settings page, mobile run settings, and Klaus's control tools cannot change it; scheduled tasks use their explicit background-task permission override.

Tool-call decision order

Ordinary tool calls check explicit rules and tool checks before applying the permission baseline:

1. A matching deny rule blocks the call. No preset overrides it.
2. A matching ask rule requires a permission card, including with "Skip all permissions" selected.
3. A denial from the tool's own check blocks the call.
4. "Skip all permissions" allows ordinary calls; the preceding rules and tool checks remain effective.
5. Sensitive-file checks can require confirmation, such as changes to executable scripts or paths affecting configuration loading. "Auto-edit" alone does not bypass these checks.
6. A matching allow rule or an explicit allowance from the tool's own check is applied.
7. The preset supplies the baseline: "Ask every time" runs read-only operations directly and asks about changes; "Auto-edit" approves file edits within writable directories, while commands and out-of-scope changes can still require confirmation. A sub-agent definition can also specify permissionMode: dontAsk, which declines changes lacking permission without prompting; it is not an ordinary composer option.
8. A call that has not been allowed raises a permission card.

Read-only is an important property of a call. Listing resources and checking status are usually read-only, but explicit deny and ask rules still apply. The optional confine_reads setting also requests confirmation for reads outside writable roots; it is off by default. Commands have additional per-subcommand checks, and an allowance for the whole command cannot override a denied subcommand.

Sandbox and friend-task scope

Permission decisions and sandbox access scope both apply. Approving an operation does not expand the conversation's file, network, or application scope.

A friend task's permission preset controls which actions require another prompt inside its approved scope. It cannot expand the approved directories or applications: out-of-scope access is denied, and read-only directories remain read-only. That scope is fixed when the session starts, so a friend-task preset change applies to the next turn; the current turn retains its original policy.