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
- Grant or deny the permission prompt before closing/reloading the plugin pane
- In multi-client setups, answer the prompt from the client that opened the plugin
- If developing against this API, treat a None from get_running_plugin as 'plugin gone' and skip the write instead of propagating an error
- 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
- Resolve permission prompts before closing or reloading the plugin pane
- In multi-client sessions, answer prompts from the client that hosts the plugin
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
- Plugin is not stored in memory
- Failed to serialize user configuration: {:?}
- Failed to convert to protobuf: {:?}
- failed to convert serialized command: {}
- Failed to serialized plugin ids: {}
AI-assisted analysis of zellij-org/zellij@98a0837077 (2026-08-16).
Data as JSON: /api/errors/110aa7efdb6e2b5a.
Report an issue: GitHub.