zellij-org/zellij · error

Failed to get running plugin

Error message

Failed to get running plugin

What it means

Thrown in the plugin-permission write path (wasm_bridge.rs) when PluginMap::get_running_plugin returns None for the given (plugin_id, client_id). The map stores assets per (plugin_id, client_id) pair, so the lookup fails when that combination was never registered or was already unloaded.

Source

Thrown at zellij-server/src/plugins/wasm_bridge.rs:1754

            };
        }
    }
    pub fn cache_plugin_permissions(
        &mut self,
        plugin_id: PluginId,
        client_id: Option<ClientId>,
        permissions: Vec<PermissionType>,
        status: PermissionStatus,
        cache_path: Option<PathBuf>,
    ) -> Result<()> {
        let err_context = || format!("Failed to write plugin permission {plugin_id}");

        let running_plugin = self
            .plugin_map
            .lock()
            .unwrap()
            .get_running_plugin(plugin_id, client_id)
            .ok_or_else(|| anyhow!("Failed to get running plugin"))?;

        let mut running_plugin = running_plugin.lock().unwrap();

        let permissions = if status == PermissionStatus::Granted {
            permissions
        } else {
            vec![]
        };

        running_plugin
            .store
            .data_mut()
            .set_permissions(HashSet::from_iter(permissions.clone()));

        let mut permission_cache = PermissionCache::from_path_or_default(cache_path);
        permission_cache.cache(
            running_plugin.store.data().plugin.location.to_string(),
            permissions,

View on GitHub (pinned to 98a0837077)

Solutions

  1. Grant or deny the permission prompt before closing/reloading the plugin pane
  2. In multi-client setups, answer the prompt from the client that opened the plugin
  3. If developing against this API, treat a None from get_running_plugin as 'plugin gone' and skip the write instead of propagating an error
  4. Retry the plugin action after re-granting; the plugin will re-request permission on its fresh instance
Defensive patterns

Strategy: type-guard

Type guard

fn plugin_alive(map: &PluginMap, plugin_id: u32, client_id: u16) -> bool {
    map.get_running_plugin(plugin_id, Some(client_id)).is_some()
}

Try / catch

match self.plugin_map.lock().unwrap().get_running_plugin(plugin_id, client_id) {
    Some(running) => { /* write permission */ },
    None => return Ok(()), // plugin gone; nothing to update
}

Prevention

When it happens

Trigger: A permission request resolves after the plugin was unloaded (UninstallPlugin/Unload instruction raced the permission grant), or the request is answered with a client_id different from the one the plugin instance is keyed under (e.g. permission granted from another connected client that has no instance of the plugin).

Common situations: Granting a permission dialog after the plugin pane was closed or the session is shutting down; multi-client sessions where the permission reply arrives on a different client; plugin auto-reload while a permission prompt is open.

Related errors


AI-assisted analysis of zellij-org/zellij@98a0837077 (2026-08-16). Data as JSON: /api/errors/110aa7efdb6e2b5a. Report an issue: GitHub.