Plugins

A plugin is a packaged bundle of capabilities: one plugin can carry skills, slash commands, sub-agents, MCP servers and hooks at the same time.

• Marketplace tab: browse and install from the plugin marketplace. The "what you get after installing" on each row is computed by the engine with the very same parser it uses when loading, so the marketplace page cannot disagree with what actually shows up once installed.
• Updates: the marketplace card and the installed list show the installed version, the available version and an "Update to" button. After refreshing the marketplace to pull a new catalog, an update hands the new version to the engine to install, keeping the enabled state and the plugin's data; on failure the current state is kept, and stale updates are rejected by the engine.
• Installed tab: the enable/disable switch. Note that plugin on/off is application-wide, with no project scope — once enabled it is visible in every session.
• "Loaded / failed to load" in the installed list is the runtime state of one particular session, not a global property: the same plugin can be healthy in a new session while an older session still holds its previous state.

How installing and activation work:

• The ledger belongs to the engine and lives in the [plugins] section of its own config file ~/.klaus/config.toml, one record per plugin with its name, source, install path, install time and enabled flag. The engine reads and writes this file, so do not introduce a second writer that changes its shape — the engine parses it at startup, and a wrong shape means it will not boot. Registered marketplace catalogs are recorded in the [marketplaces] section of the same config.
• Installing has two stages: the client first fetches the package into a staging directory (a local copy, or a git fetch — repository URLs, the owner/repo shorthand and fetching just one subdirectory of a repository are all supported), then hands it to the engine to validate, copy into its own storage area and write the ledger. The staging directory is cleaned up whether it succeeded or failed, so a failed install never leaves half a plugin behind.
• Toggling flips the enabled flag in the ledger. Installing, enabling and disabling never require restarting the app, and sessions that are already open pick up the skills a newly installed plugin brings. (In a few cases — a publish failure, or an old format that needs migrating — the engine reports that a new connection is required.)
• Uninstalling removes both the ledger row and the copy in the storage area. The built-in ones (the browser, for example) are tagged as built-in sources: they can be disabled but not uninstalled.
• The skills, commands, sub-agents, MCP servers and hooks inside a plugin are loaded by the engine from the ledger and tagged with their source; the client does not report them again (otherwise a plugin's hooks would fire twice per event).