Cua Driver Permission Modes: Standard, Bounded, Unrestricted

Cua Driver enforces authorization inside the native runtime, after transport arguments are sanitized and before any platform action runs. CLI, MCP, direct SDK, and service-backed calls all reach the same enforcement boundary. The mode is fixed when the runtime starts — an agent cannot change it, and neither can you change it on a running daemon. Stop the daemon and restart it with different flags to change the mode.

The three modes

Mode	Best for	Runtime behavior
`standard`	Normal local CLI and MCP use	Routine observation, input, file transfer, isolated browser use, and recording run without prompts. Residual boundaries — such as attaching to an existing logged-in Chromium profile — still need an explicit grant.
`bounded`	Unattended agents, gateways, embedded applications	Only tools and resources declared in a launch-approved manifest may run. In-scope work is silent. Out-of-scope work is denied.
`unrestricted`	Disposable or fully trusted environments	Cua approval checks are bypassed after an explicit dangerous acknowledgement. Hard invariants and configured policy ceilings still apply.

standard is the default. A plain cua-driver mcp or cua-driver serve with no flags runs in standard mode.

Unrestricted mode does not defend against prompt injection or unintended model actions. Use it only where you accept the full effect of every capability allowed by the built-in, managed, and user policy ceilings.

Set mode at launch via flags

Pass flags to cua-driver serve. On macOS the flags go after serve in the open command so TCC attribution stays with CuaDriver.app.

standard (default)
bounded
unrestricted

cua-driver serve

No flags needed. Standard is always the default.

cua-driver serve \
  --permission-mode bounded \
  --session-policy ~/cua-session.yaml \
  --approve-session-policy

--approve-session-policy confirms that the trusted launcher reviewed this exact file. The manifest path must be absolute on macOS.

cua-driver serve --dangerously-bypass-approvals

--permission-mode unrestricted without --dangerously-bypass-approvals fails closed.

Set mode via environment variables

Launchers that cannot pass CLI flags — cua-driver mcp owning its own runtime on Windows and Linux, a Windows Scheduled Task, or an embedding host — use these environment variables:

CLI flag	Environment variable
`--permission-mode <mode>`	`CUA_DRIVER_PERMISSION_MODE=<mode>`
`--session-policy <path>`	`CUA_DRIVER_SESSION_POLICY_FILE=<path>`
`--approve-session-policy`	`CUA_DRIVER_SESSION_POLICY_APPROVED=1`
`--dangerously-bypass-approvals`	`CUA_DRIVER_DANGEROUSLY_BYPASS_APPROVALS=1`

Variables accept 1, true, yes, or on for boolean values. The CLI flag normalizes mode plus acknowledgement in one step; the environment form does not:

unrestricted requires both CUA_DRIVER_PERMISSION_MODE=unrestricted and CUA_DRIVER_DANGEROUSLY_BYPASS_APPROVALS=1.
bounded requires both CUA_DRIVER_SESSION_POLICY_FILE and CUA_DRIVER_SESSION_POLICY_APPROVED=1.

Missing halves fail startup instead of downgrading silently to standard. CUA_DRIVER_SESSION_POLICY_FILE and CUA_DRIVER_SESSION_POLICY_APPROVED are rejected in standard and unrestricted mode.

These variables are trusted launch configuration on the same footing as CLI flags. Whoever can write them for the daemon’s environment sets its mode. An agent tool call can never set them.

What standard mode allows

Operation	Standard behavior
Observe windows, applications, and the desktop	Allow
Click, type, scroll, drag, and focus	Allow
Create and use a driver-owned isolated browser	Allow
Read visible page content through typed browser tools	Allow
Upload, download, screenshot, record, and replay	Allow
Terminate a process proven launched by this runtime	Allow after process fingerprint revalidation
Terminate a foreign process	Deny
Attach to an existing logged-in Chromium profile	Require an explicit launch grant: `cua-driver mcp --grant existing-profile`
Run unbounded legacy page mutation scripts	Deny
Raise an OS permission prompt from an agent tool call	Deny

Write a bounded manifest

A bounded manifest is a YAML file that declares the exact tools and resources an agent may use. The runtime refuses to start if the manifest conflicts with the built-in rules — for example, declaring browser origins alongside generic input tools. Below is a complete application-automation manifest:

version: 2
mode: bounded
expires_after: 8h
idle_timeout: 30m

allow:
  tools:
    - start_session
    - end_session
    - launch_app
    - get_window_state
    - click
    - type_text
    - press_key
    - kill_app

resources:
  apps:
    # macOS: use bundle_id instead of executable
    - bundle_id: com.example.Editor
      launch: true
      windows: all
      terminate: driver_launched
    # Windows/Linux: use absolute executable path
    # - executable: /usr/bin/example-editor

  files:
    read:
      - dir: /data/input
        recursive: true
    write:
      - dir: /data/output
        recursive: true

  desktop:
    display: false

For browser-only automation, use a separate browser manifest. A manifest that declares resources.browser.origins cannot also allow the generic input tools (click, type_text, press_key, etc.) — those bypass the typed browser origin adapter and the runtime refuses to start:

version: 2
mode: bounded
expires_after: 8h
idle_timeout: 30m

allow:
  tools:
    - start_session
    - end_session
    - launch_app
    - list_windows
    - browser_prepare
    - get_browser_state
    - browser_navigate
    - browser_click
    - browser_type
    - browser_download

resources:
  browser:
    profiles:
      - kind: isolated
    origins:
      - https://app.example.com

  desktop:
    display: false

Key manifest rules

Unknown tools and missing resources fail closed.
Browser origins match exact scheme, host, and port.
Declaring browser origins excludes generic input tools from the same manifest.
terminate: driver_launched requires a fresh process fingerprint match.
ask.tools is denied in unattended use — an agent cannot approve its own request.
Keep expires_after and idle_timeout as short as the task permits.
A manifest bounds one runtime’s tool surface. It does not sandbox other processes running as the same user.

Start a bounded daemon

cua-driver serve \
  --permission-mode bounded \
  --session-policy ./cua-session.yaml \
  --approve-session-policy

Then point an MCP client at the running daemon’s socket:

{
  "mcpServers": {
    "cua": {
      "command": "cua-driver",
      "args": ["mcp", "--socket", "/path/to/cua-driver.sock"]
    }
  }
}

Use the socket path reported by cua-driver status unless your launcher selected a custom --socket.

Test denial before unattended use

Confirm all three cases before running an agent unattended:

An allowed tool against an allowed resource succeeds without a Cua prompt.
An allowed tool against a different app, origin, or path returns bounded_resource_outside_manifest.
A tool omitted from allow.tools returns permission_denied.

Also test revocation:

cua-driver revoke --session test-run
cua-driver revoke --all

revoke --all suspends the complete runtime generation. Restart the daemon before starting a new bounded run.

Authorization stack

Every call must pass all applicable layers in order:

Hard invariants (self-targeting and protected-host checks).
The reviewed built-in tool and risk map.
Administrator policy from CUA_DRIVER_MANAGED_POLICY_FILE, when set.
User policy from CUA_DRIVER_POLICY_FILE, when set.
The bounded manifest, when the active mode is bounded.
A launch grant or trusted host authorization for residual standard-mode boundaries.

No grant or permission mode can widen a managed or user policy. A new tool added to the driver is not automatically exposed to agents — each tool must be explicitly permitted.

Next steps

Connect Agent

Background Delivery

How agents act without stealing focus or moving your cursor.

Get Started

Concepts

Cua Driver

Cua Sandbox

Lume

Cua Bench

Use Cua With

Cua Driver Permission Modes: Standard, Bounded, Unrestricted

The three modes

Set mode at launch via flags

Set mode via environment variables

What standard mode allows

Write a bounded manifest

Key manifest rules

Start a bounded daemon

Test denial before unattended use

Authorization stack

Next steps

Connect Agent

Background Delivery

Build docs developers (and LLMs) love

Get Started

Concepts

Cua Driver

Cua Sandbox

Lume

Cua Bench

Use Cua With

Documentation Index

​The three modes

​Set mode at launch via flags

​Set mode via environment variables

​What standard mode allows

​Write a bounded manifest

​Key manifest rules

​Start a bounded daemon

​Test denial before unattended use

​Authorization stack

​Next steps

Connect Agent

Background Delivery

Build docs developers (and LLMs) love

The three modes

Set mode at launch via flags

Set mode via environment variables

What standard mode allows

Write a bounded manifest

Key manifest rules

Start a bounded daemon

Test denial before unattended use

Authorization stack

Next steps