Gracefully handle plugin init failures#424
Conversation
Previously, if any plugin failed to initialize (e.g. missing directory), the entire app would crash via .expect(). Now individual plugin failures are stored on the PluginManager and surfaced to the user as warning toasts once the window is ready. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 99ebd04eb3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // Check for plugin initialization errors | ||
| invokeCmd<[string, string][]>('cmd_plugin_init_errors').then((errors) => { | ||
| for (const [dir, message] of errors) { | ||
| const dirBasename = dir.split('/').pop() ?? dir; |
There was a problem hiding this comment.
dirBasename is derived with dir.split('/'), which only works for POSIX paths. When a plugin directory is reported with Windows separators (e.g. C:\...\plugin), this expression returns the full absolute path instead of the basename, so the warning toast shows noisy paths and generates unstable IDs from full paths rather than plugin names. This is a cross-platform regression in the new startup-error toast flow; parse both \ and / separators before building the toast content/ID.
Useful? React with 👍 / 👎.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Summary
PluginManagerinstead of crashing the app when a plugin fails to load (e.g. missing directory)cmd_plugin_init_errorscommand so the frontend can query errors once the window is readycmd_reload_pluginsnow returns errors instead of silently discarding themTest plan
🤖 Generated with Claude Code