Security model (desktop)

The Wayland desktop app and the Wayland Core CLI are both designed to limit what an AI agent can do without your knowledge. However, they use different mechanisms, offer different guarantees, and operate in different threat environments. This page explains the desktop model.

The approval layer

The most visible safety mechanism in the desktop app is the approval prompt. Before an agent calls a tool that touches your system (running a shell command, writing a file, making a network request), Wayland shows a permission dialog. You approve or deny each call.

This is the foundation. Tool approvals are the first line of protection in the default configuration.

The approval behavior changes with the mode you select:

Mode	What is auto-approved	What requires approval
Default	Nothing	Every tool call
Accept Edits	File edits only	Command execution, network calls
Autopilot	Almost everything	Commands matching the catastrophic-pattern list

You set the mode per conversation or per run from the conversation toolbar.

The Autopilot guardrail

Autopilot (internally: autoGuarded mode) is not the same as raw “bypass permissions.” It auto-approves tool calls in bulk, but one classifier remains active: the catastrophic-command guardrail.

The guardrail examines every proposed shell command before it executes. If the command matches a pattern in the catastrophic list, auto-approval is blocked and a real confirmation surfaces to you. The list is narrow and high-bar:

• Recursive deletion of / or ~, or top-level system directories (/etc, /usr, /boot).
• rm --no-preserve-root.
• Raw writes to block devices (dd of=/dev/...).
• Filesystem formatting (mkfs).
• Fork bombs.
• Recursive permission or ownership changes on root or home.
• Network-fetched content piped directly into a shell (curl | bash, wget | sh).
• Overwrites of core system files (/etc/..., /boot/..., /sys/...).
• find / -delete.

Everything else (deleting build artifacts, running git, installing packages, editing project files) is auto-approved in Autopilot without interruption. False positives stall legitimate work, so when the classifier is uncertain, it allows the command through rather than interrupting.

See Autopilot and the Safety Guardrail for the full guardrail list and what happens when it trips.

The guardrail is a backstop, not a sandbox

The guardrail pattern-matches command strings. Obfuscation, variable expansion, or multi-step commands can evade it. It is designed to catch the obvious rm -rf ~ or curl | bash class of accident in an unattended run, not to enforce hard isolation. Do not rely on it as your only safeguard on a machine you care about.

Consent hardening (0.11.9 and later)

The 0.11.9 through 0.11.18 desktop series rebuilt the approval path around one rule: nothing acts without your say-so. Each piece was independently cross-audited before it shipped.

• Approvals are bound to the action. An approval carries a server-generated secret tied to the exact tool call it approves, so a yes to one action can never be correlated with or replayed onto another.
• Auto-approving modes are a launch-time opt-in. A wire peer (a paired device, a programmatic client) can no longer switch the engine into an auto-approving mode; that opt-in is taken by the local operator at boot, and the desktop manages it for the bundled engine so Autopilot keeps working normally.
• Project config can only tighten your posture. A folder you open can make the rules stricter; directives that would loosen them are ignored, and project hooks are default-deny until you explicitly trust them.
• Remote surfaces are consent-gated. Paired devices cannot reach scheduled-task write or execute commands, the app announces every LAN bind and asks before exposing it, and remote peers cannot write desktop configuration.
• Secrets stay out of the timeline. Inline secrets are redacted from the tool-command display, a denied approval reads as denied rather than success, and agent email sends pass a hard per-send confirmation gate in every mode.

What is and is not sandboxed in the desktop app

The desktop app runs on your machine as a native Electron process. It has the same filesystem, network, and process privileges as your user account. There is no OS-level process sandbox applied to the agent’s tool calls by default in the desktop app.

What the desktop does enforce:

• Workspace confinement: when a conversation has a project workspace set, file operations are scoped to that directory. The agent sees only the workspace tree for file-targeting tool calls.
• Per-provider toggles: providers can be disabled, limiting which model endpoints the agent can reach.
• Budget and cost caps: you can set per-session spend limits from the conversation settings.
• Approval prompts: covered above.

What the desktop does not enforce:

• OS process sandboxing: there is no bubblewrap, Seatbelt, AppContainer, or equivalent applied to the agent’s shell commands on the desktop. A shell command that escapes the workspace directory is not blocked by the OS.
• Network egress filtering: the desktop does not run a per-call egress gate equivalent to Wayland Core’s EgressClient. Outbound network calls are limited only by the tool approval prompt.

This is a deliberate design trade-off. The desktop app is primarily a GUI command center for users who review and approve agent actions interactively. The approval layer is the primary control. For automated, unattended, or multi-agent runs where hard OS isolation matters, Wayland Core provides it.

How this differs from the Wayland Core CLI sandbox

Wayland Core runs every shell command inside an OS-native sandbox selected at startup:

• Linux: Bubblewrap (bwrap), optionally with Landlock LSM and libseccomp
• macOS: sandbox-exec (Seatbelt/SBPL profile)
• Windows: AppContainer and Job Objects
• Everywhere: Docker (opt-in)

The Core sandbox restricts which paths the process can read and write, which network calls it can make, and (on Linux) which syscalls it can invoke. If the sandbox backend is unavailable and WAYLAND_ALLOW_NO_SANDBOX=1 is not set, the engine refuses to run rather than degrading silently.

Core also runs a network egress gate that inspects every outbound HTTP call against an allow-list and a shared-platform blocklist before it leaves the process.

The desktop app does not expose these OS sandbox layers. When you embed the Wayland engine (wayland-core) inside the desktop app as an ACP backend, those Core sandbox policies apply to that subprocess, but the desktop’s own native tool dispatch is not sandboxed at the OS level.

Feature	Desktop app	Wayland Core CLI
OS process sandbox	No	Yes (bwrap / Seatbelt / AppContainer)
Network egress gate	No	Yes
Catastrophic-command guardrail	Yes (Autopilot mode)	No (separate approval-mode system)
Workspace confinement	Yes (project scope)	Yes (--project-dir flag)
Tool approval prompts	Yes	Yes
Budget caps	Yes	Yes

What to do in practice

For interactive use where you review each step, the default approval mode with workspace confinement is the right starting point. For longer automated runs with Autopilot, the guardrail adds a safety net without requiring you to watch every command.

If you are running agents unattended over sensitive data or in a multi-tenant environment, consider running the Wayland engine as a Core CLI subprocess or self-hosted server instead, where the OS sandbox applies.

Next

• Autopilot and the Safety Guardrail
• Permissions and Sandboxing
• Security Model Overview (Core)
• Shell Sandbox (Core)