Documentation Index
Fetch the complete documentation index at: https://docs.qoder.com/llms.txt
Use this file to discover all available pages before exploring further.
options.plugins is used to load local plugin directories into the current query session. The SDK converts each local plugin into a --plugin-dir <path> startup argument; commands, agents, skills, and MCP servers included in the plugin are automatically discovered and available for the session.
Loading Local Plugins
Plugin Directory Layout
A local plugin typically contains:.qoder-plugin/plugin.json declares the plugin name, version, and description. The other directories are automatically scanned by the CLI based on file type.
Plugin-contributed Slash Commands
commands/*.md files in the plugin will appear in the initialization result and in supportedCommands().
Plugin-contributed Agents
agents/*.md files in the plugin will appear in the initialization result and in supportedAgents().
Plugin-contributed Skills
skills/*/SKILL.md files in the plugin are registered with a plugin-qualified name (plugin:skill). To make them callable in the main session, they must be explicitly listed in options.skills; see Skills documentation.
Plugin-contributed MCP Servers
.mcp.json in the plugin is started by the CLI and included in the MCP status.
Temporarily Overriding an Installed Plugin with the Same Name
Plugins loaded viaoptions.plugins are session-scoped. During the current session, if a local plugin shares a name with an installed plugin, the local plugin takes priority in capability discovery. This is useful for plugin development, debugging, and canary testing.
Reloading Plugins at Runtime
If the plugin directory changes, you can callreloadPlugins() within the same query session to have the CLI rescan plugin resources.
- Refreshing after adding or deleting
commands/*.mdduring plugin development. - After installing or updating a local plugin without restarting the host application.
- When the host UI needs to display commands, agents, plugins, and MCP status after a reload.
Options Reference
| Field | Type | Description |
|---|---|---|
plugins | SdkPluginConfig[] | Load local plugin directories; currently the common form is { type: 'local', path } |
settings | string | Settings | Settings passed to the CLI, which can include fields like enabledPlugins, pluginConfigs, etc. |
settingSources | ('user' | 'project' | 'local')[] | Controls which settings sources the CLI reads |
settings.enabledPlugins, settings.pluginConfigs, settings.allowedChannelPlugins, and settings.strictPluginOnlyCustomization are passed through by the SDK types, but the actual pipeline depends on the specific CLI version. Verify against your environment before use.
Return Value Reference
initializationResult()
reloadPlugins()
Best Practices
- Read
initializationResult()first for the host UI: It is the stable entry point for displaying commands, agents, skills, and plugins. - Use
options.pluginsduring plugin development: It only affects the current session without modifying the user’s global install state. - Prepare user prompts before reloading:
reloadPlugins()triggers the CLI to rescan disk, which may briefly change the available resource list; synchronize UI updates accordingly. - Check
error_countfor diagnostics: Iferror_count > 0after reload, some plugin resources failed to load; display the source to the user.
Current Limitations
- In some qodercli versions, local plugin commands, agents, and MCP can appear correctly in the initialization result, but plugin skills may not appear in
initializationResult().skills— this is a CLI-side discovery pipeline issue. - Under the current qodercli implementation, non-existent
--plugin-dirpaths are silently ignored in SDK mode; to explicitly diagnose plugin loading failures, currently the only option isreloadPlugins().error_countas a fallback. reloadPlugins()is a runtime control API exposed by the SDK; if the current CLI version returns internal errors related tothis._plugins, an upgrade to the fixed qodercli is needed.