Capabilities: The 2.0 ACL

"A capability is a sentence: 'these windows may use these powers.' Everything in Tauri's security model is variations on that sentence."

What a Capability File Is

Capabilities live as JSON files in src-tauri/capabilities/. Each one binds a set of permissions to a set of windows. The shape is small and readable: an identifier (a name for this capability), a description, a windows array (which window labels it applies to), and a permissions array (the powers it grants). Tauri reads every file in that folder at build time and assembles the access-control list for your app.

Reading a Real One

Look at Cinder's actual capability. It applies to the main window and grants a focused set: core:default (the baseline safe APIs), two specific window permissions for always-on-top behavior, and the default permission sets of three plugins (store, clipboard-manager, window-state). Notice what's not there: no filesystem, no shell, no broad network. Cinder grants exactly the powers it uses and nothing more — the file is a precise inventory of what the app is allowed to do.

Different Windows, Different Powers

Because a capability names which windows it applies to, you can give windows different privilege levels. Your main window might need clipboard and store access; a settings window might need almost nothing. Split capabilities by window so a less-trusted or simpler window can't reach powers it has no business using. This is least privilege expressed structurally — the per-window grant is a feature you should actively use, not a detail to ignore.

Code

A precise, real capability (note: no fs, no shell)·json

// src-tauri/capabilities/default.json — Cinder's real capability.
// 'The main window may use these specific powers, and only these.'
{
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "default",
  "description": "Capability for the main window",
  "windows": ["main"],
  "permissions": [
    "core:default",
    "core:window:allow-set-always-on-top",
    "core:window:allow-is-always-on-top",
    "store:default",
    "clipboard-manager:allow-write-image",
    "window-state:default"
  ]
}

Exercise

Open your app's capabilities/default.json and read it line by line. Identify what each permission grants. Then remove core:default temporarily, run the app, and watch built-in functionality break — that proves the capability is really the gate, not decoration. Put it back, and you've felt the ACL do its job.

Hint

core:default bundles the baseline safe APIs most apps need. Removing it is a quick way to see that nothing is granted implicitly — even basic window operations flow through permissions.