tauri-apps/tauri · error
failed to read capabilities
Error message
failed to read capabilities
What it means
Thrown at build time when the generated capabilities file (CAPABILITIES_FILE_NAME, e.g. capabilities.json) exists in the build output dir but cannot be read with `std::fs::read_to_string`. As with the manifest map, existence was just checked, so failure implies permission problems, a race where the file vanished, or path/type issues.
Solutions
- Delete the stale capabilities file / `cargo clean` and rebuild.
- Fix permissions or rebuild as the user that owns the generated files.
- Avoid parallel builds sharing one target directory.
- Re-run the tauri CLI to regenerate the capabilities file.
Example fix
# before: unreadable generated capabilities file rm -f src-tauri/target/*/build/*/out/capabilities.json cargo tauri build
Defensive patterns
Strategy: validation
Validate before calling
const fs = require('fs');
// pre-build check: generated capabilities file, if present, must be readable
const candidates = ['src-tauri/target/dev/build', 'src-tauri/target/release/build'];
for (const dir of candidates) {
if (!fs.existsSync(dir)) continue;
for (const f of findRec(dir, 'capabilities.json')) {
try { fs.accessSync(f, fs.constants.R_OK); } catch { console.error(`unreadable: ${f} — delete it or fix permissions`); }
}
} Prevention
- Build consistently as one user; clean after switching
- Exclude target dirs from antivirus/sync tooling
- Avoid concurrent builds into the same target directory
- Clean cached target dirs in CI when users differ
When it happens
Trigger: Running `tauri build`/`tauri dev` when capabilities.json exists in the out dir but is unreadable: ownership/permission mismatch from a prior build as another user, deleted between check and read, or concurrent builds.
Common situations: CI runners reusing cached target dirs with different users; concurrent dev/build invocations; antivirus or sync tools locking the file.
Understand the failure class
Background: "failed to read file", EACCES, ENOENT and "could not read <path>" errors: when a program can't read a file from disk — this error's family across 49 libraries.
Related errors
- failed to read plugin manifest map
- failed to read plugin global API script paths
- unable to find isolation file
- embedded file asset has no parent
- failed to canonicalize global API script path
AI-assisted analysis of tauri-apps/tauri@460ec35447 (2026-09-18).
Data as JSON: /api/errors/15e53693131caf34.
Report an issue: GitHub.
Appendix: source
Thrown at crates/tauri-codegen/src/context.rs:407
key: #key.into(),
crypto_keys: std::boxed::Box::new(::tauri::utils::pattern::isolation::Keys::new().expect("unable to generate cryptographically secure keys for Tauri \"Isolation\" Pattern")),
})
}
};
let acl_file_path = out_dir.join(ACL_MANIFESTS_FILE_NAME);
let acl: BTreeMap<String, Manifest> = if acl_file_path.exists() {
let acl_file =
std::fs::read_to_string(acl_file_path).expect("failed to read plugin manifest map");
serde_json::from_str(&acl_file).expect("failed to parse plugin manifest map")
} else {
Default::default()
};
let capabilities_file_path = out_dir.join(CAPABILITIES_FILE_NAME);
let capabilities_from_files = if capabilities_file_path.exists() {
let capabilities_json =
std::fs::read_to_string(&capabilities_file_path).expect("failed to read capabilities");
serde_json::from_str(&capabilities_json).expect("failed to parse capabilities")
} else {
Default::default()
};
let capabilities = get_capabilities(
&config,
capabilities_from_files,
additional_capabilities.as_deref(),
)
.unwrap();
let resolved = Resolved::resolve(&acl, capabilities, target).expect("failed to resolve ACL");
let acl_tokens = map_lit(
quote! { ::std::collections::BTreeMap },
&acl,
str_lit,
identity,View on GitHub (pinned to 460ec35447)