What causes "failed to read plugin manifest map" in tauri-apps/tauri?

Run cargo clean (or delete the app crate's target directory) and rebuild

failed to read plugin manifest map

Error message

failed to read plugin manifest map

What it means

Build-time panic in tauri-codegen while loading the ACL manifest cache. tauri-build writes acl-manifests.json into OUT_DIR during dependency collection; tauri-codegen later does std::fs::read_to_string(acl_file_path).expect("failed to read plugin manifest map"). Because the exists() check already passed, the read itself failed — permissions changed, the file was deleted or locked between check and read, or the content is non-UTF-8.

Source

Thrown at crates/tauri-codegen/src/context.rs:396

      if !sets_isolation_hook {
        panic!("The isolation application does not contain a file setting the `window.__TAURI_ISOLATION_HOOK__` value.");
      }

      let schema = options.isolation_schema;

      quote!(#root::Pattern::Isolation {
        assets: ::std::sync::Arc::new(#assets),
        schema: #schema.into(),
        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(),
  )

View on GitHub (pinned to 52e4b6e71d)

Solutions

Run cargo clean (or delete the app crate's target directory) and rebuild
Ensure only one cargo process builds the workspace at a time (lock the target dir in CI)
Fix ownership/permissions of target/ (chown -R) and avoid mixing root and user builds
Exclude the target directory from antivirus/backup scanning that may lock files

Example fix

# before: panic: failed to read plugin manifest map

# after
cargo clean && cargo build

Defensive patterns

Strategy: validation

Validate before calling

# CI: serialize builds on a shared target dir and clean interrupted artifacts
find target -name acl-manifests.json -size -10c -delete 2>/dev/null || true
cargo clean -p "$APP_CRATE" 2>/dev/null || true

Prevention

Never run two cargo builds against the same target directory concurrently
Avoid mixing root and user builds; keep target/ owned by the build user
Exclude target/ from antivirus and backup scanners

When it happens

Trigger: generate_context! reading OUT_DIR/acl-manifests.json while a concurrent cargo process, antivirus, or cache cleaner removes/locks it; a target directory shared between users with different permissions; a truncated artifact left by a killed build.

Common situations: Two cargo/rust-analyzer builds racing in the same target dir (CI matrix jobs sharing a volume); cargo killed mid-build leaving a zero-byte file; permission flips after one build step ran as root.

Related errors

AI-assisted analysis of tauri-apps/tauri@52e4b6e71d (2026-08-20). Data as JSON: /api/errors/a38ace348e3f53d9. Report an issue: GitHub.