Skip to content

Permissions and consent

Owner-controlled configuration is read at broker startup. An agent request cannot replace the profile, grant itself additional authority, or approve its own action.

[policy]
profile = "observe"

The observe profile covers desktop, application, window, UI and process metadata. It does not imply access to clipboard contents, screenshots, keyboard input or application-native mutations.

desktop adds window management, semantic UI mutation and notifications. workspace and developer do not silently enable unrestricted filesystem access or a shell. Separate permissions remain required. Explicit deny entries take precedence over baseline and allow entries.

Named filesystem grants declare a canonical root and read/write authority. Roots may not overlap protected broker paths or special system filesystems. The Linux implementation uses directory-relative resolution rather than relying only on string-prefix comparisons.

Application-native paths may have additional limitations. Read the application’s driver notes before assuming the same confinement guarantees apply to every API.

Destructive, secret-access, code-execution and privilege-sensitive requests need human approval after capability checks. A foreground daemon with --approval-console receives the operator’s answer on its own terminal. A systemd user service has no approval console and can return ConsentRequired.

A model-provided confirmation field, an automatic “yes”, or a recipe argument is not a substitute for that operator decision. Do not give the requesting agent direct access to the approval terminal.

Approving a broker request does not dismiss the compositor’s chooser. Approving a portal session does not grant every broker command. Both layers must be satisfied, and changes or revocations must remain visible.

Source: permission reference, reviewed 22 September 2026. See also the security model.