options.plugins is used to load local plugin directories into the current session. The SDK converts each local plugin into a --plugin-dir <path> startup argument; commands, agents, skills, and MCP servers contained in the plugin all take part in capability discovery for the session.
Loading Local Plugins
--plugin-dir arguments will be written in order:
💡query()is a one-shot message stream; it cannot query the init response after the handshake. To read commands / agents / skills contributed by plugins, useQoderSDKClientand callget_server_info()afterconnect(), or captureSystemMessage(subtype='init')in the message stream and readmessage.datayourself. To read the complete plugin inventory, callclient.list_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.
The SDK does not validate whether the path exists or is well-formed:
- A non-existent
--plugin-dirpath is silently ignored in SDK mode; the session still initializes normally. - Broken frontmatter or
.mcp.jsondoes not block init; broken commands simply do not appear in the init response. - To explicitly diagnose plugin loading failures, the only fallback right now is
reload_plugins().error_count.
Plugin-contributed Slash Commands
commands/*.md files in a plugin appear in get_server_info()['commands'], with names in the plugin-qualified form <plugin>:<cmd>.
Plugin-contributed Agents
agents/*.md files in a plugin appear in get_server_info()['agents']. The SDK also provides a synchronous convenience method for getting this list directly:
Plugin-contributed Skills
skills/<name>/SKILL.md files in a plugin are registered with a plugin-qualified name (plugin:skill). Use options.skills to control their main-session context visibility and invocation policy: pass a qualified name to enable one skill, pass "all" to enable every discovered skill, or omit it to use the CLI's default policy. See Skills documentation.
Plugin-contributed MCP Servers
.mcp.json in a plugin is started by the CLI and included in the MCP status, which can be read via get_mcp_status():
Temporarily Overriding an Installed Plugin with the Same Name
Local plugins loaded through options.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 for the session. This is useful for plugin development, debugging, and canary testing.
Reloading Plugins at Runtime
If the plugin directory changes, you can call reload_plugins() within the same QoderSDKClient 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.
Note:reload_plugins()is only meaningful inQoderSDKClient(streaming) mode; the one-shotquery()stream has no runtime control channel.
Options Reference
| Field | Type | Description |
|---|---|---|
plugins | list[SdkPluginConfig] | Loads local plugin directories; currently the common form is {"type": "local", "path": ...} |
settings | str | Path | dict[str, Any] | None | Settings passed to the CLI, which can include fields like enabledPlugins, pluginConfigs, etc. |
setting_sources | list[Literal["user", "project", "local"]] | None | Controls which settings sources the CLI reads |
settings.enabledPlugins to control plugin enablement and settings.pluginConfigs to provide plugin configuration.
Return Value Reference
client.get_server_info() and SystemMessage(subtype='init').data
client.get_server_info() returns initialization resources discovered for the current session, including commands, agents, and skills. It has no stable plugin-inventory field; see SDKControlInitializeResponse for the full return type.
client.list_plugins()
get_server_info()['plugins'].
Each item is a PluginDetails object with id, name, source, path, version, scope, enabled, canDisable, and a resources summary grouped into skills, agents, mcpServers, commands, and hooks.
client.reload_plugins()
Returns ReloadPluginsResponse:
Best Practices
- Separate initialization resources from plugin inventory: Use
get_server_info()for discovered commands, agents, and skills; uselist_plugins()for plugin inventory. Skills in the initialization result are a discovery inventory, not every skill currently invokable in the main session. - Use
options.pluginsduring plugin development: It only affects the current session and does not require modifying the user's global install state. - Prepare user prompts before reloading:
reload_plugins()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 a reload, some plugin resources failed to load; display the source to the user.
Current Limitations
- Under the current qodercli implementation, non-existent
--plugin-dirpaths are silently ignored in SDK mode; to explicitly diagnose plugin loading failures, the only fallback right now isreload_plugins().error_count. reload_plugins()is a runtime control API exposed byQoderSDKClient; if the current CLI version returns internal errors related tothis._plugins, an upgrade to a fixed qodercli is needed.