What causes "failed to read plugin global API script {}: {e}" in tauri-apps/tauri?

Run `cargo clean` (or clean the affected plugin) and rebuild so the plugin's build script regenerates the global API script.

tauri-apps/tauri · error

failed to read plugin global API script

Error message

failed to read plugin global API script {}: {e}

What it means

`read_global_api_scripts` reads each path from a plugin's `global-api-script` build output so the scripts can be injected into every webview. If any listed script file cannot be read from disk, the build/runtime panics. The file was registered (usually via build script output) but is missing or unreadable.

Solutions

Run `cargo clean` (or clean the affected plugin) and rebuild so the plugin's build script regenerates the global API script.
Verify the plugin in the message supports/enables the feature that emits its global API script and re-add/install it correctly.
Check the file exists and is readable at the path printed in the message; fix permissions if needed.
Update the plugin and tauri crates to matching versions, since script path handling changed across versions.

Example fix

// before: stale path cached
cargo build // panics reading target/.../global-script.js
// after
cargo clean && cargo build

Defensive patterns

Strategy: validation

Validate before calling

// verify plugin global api scripts exist before build
const fs = require('fs');
const exists = (p) => fs.existsSync(p) && fs.statSync(p).isFile();

Prevention

Run cargo clean when plugin script paths go stale after upgrades
Install plugins via cargo/cargo-tauri rather than copying build outputs manually
Check that plugin features emitting global API scripts are enabled in your Cargo features

When it happens

Trigger: A plugin declared a global API script path (via `tauri_build::InlinedPlugin` / build script stdout `global-api-script` lines) but `fs::read_to_string` fails at read time — file deleted, moved, or never generated.

Common situations: Stale cargo build caches pointing at removed target-dir files; a plugin's build script skipped generation (feature disabled) while the path was still emitted; permission problems on 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

AI-assisted analysis of tauri-apps/tauri@460ec35447 (2026-09-18). Data as JSON: /api/errors/8be3bf24c68ec546. Report an issue: GitHub.

Appendix: source

Thrown at crates/tauri-utils/src/plugin.rs:79

  /// Read global api scripts from [`GLOBAL_API_SCRIPT_FILE_LIST_PATH`]
  pub fn read_global_api_scripts(out_dir: &Path) -> Option<Vec<String>> {
    let global_scripts_path = out_dir.join(GLOBAL_API_SCRIPT_FILE_LIST_PATH);
    if !global_scripts_path.exists() {
      return None;
    }

    let global_scripts_str = fs::read_to_string(global_scripts_path)
      .expect("failed to read plugin global API script paths");
    let global_scripts = serde_json::from_str::<Vec<PathBuf>>(&global_scripts_str)
      .expect("failed to parse plugin global API script paths");

    Some(
      global_scripts
        .into_iter()
        .map(|p| {
          fs::read_to_string(&p).unwrap_or_else(|e| {
            panic!(
              "failed to read plugin global API script {}: {e}",
              p.display()
            )
          })
        })
        .collect(),
    )
  }
}

View on GitHub (pinned to 460ec35447)