Tauri v2 uses a capability system to control which plugin commands your frontend is allowed to call. Each command exposed by tauri-plugin-configurate has a corresponding allow-* permission identifier. You list the permissions you want to grant inside a capability file (typically src-tauri/capabilities/default.json), and Tauri enforces them at the IPC boundary — a command that is not listed will be denied before it reaches Rust. This page covers every permission identifier the plugin defines and explains when to use each one.
configurate:default
The configurate:default permission set bundles every general-purpose command the plugin exposes. It is the right starting point for most applications. Add it to your capability file like this:
The following individual permissions are included in configurate:default:
Grant only the permissions your application actually uses. If your app never watches files, omitting configurate:allow-watch-file and configurate:allow-unwatch-file reduces the surface area available to a compromised renderer process.
configurate:allow-unlock
The allow-unlock permission gates the unlock command, which is the only command that reads keyring secrets and inlines them into config data. It is intentionally excluded from configurate:default and must be granted separately.
You need this permission whenever your JavaScript code calls .unlock() on a Configurate instance or uses loadAll().unlock(). Without it, those calls are denied at the IPC layer before any keyring access occurs.
configurate:allow-unlock is deliberately kept out of the default permission set as a security measure. Granting keyring access is a meaningful decision — an application that never uses the keyring should not expose this command at all. Always add configurate:allow-unlock explicitly and only in capability files for windows that genuinely require it.
Granting individual permissions
Instead of using the configurate:default bundle, you can list only the specific permissions your application needs. This is useful when you want a tightly scoped capability file for a particular window or context:
Full permission identifier reference
The table below lists every allow-* and deny-* identifier the plugin exposes. The deny-* variants let you explicitly block a command even when a broader permission set might otherwise include it — useful for fine-grained per-window capability rules.
