Feature request: Support plugin loading / installation via SDK

[MattKotsenas]

Today, the session config allows for configuring skills, MCP servers, etc. directly. Increasingly, people are shipping plugins that bundle multiple extension types together to accomplish a scenario. In order to avoid re-creating plugin installation support in every app, the SDK should provide a "plugin loader" that is a blessed implementation of plugin installation:

• Clones / downloads the plugin
• Unpacks to a temp directory
• Parses plugin.json and creates corresponding McpSever, SkillDirectory, etc. entries

[github-actions]

Thanks for opening this feature request!

This is a clear enhancement proposal for adding plugin loading/installation support across all SDKs. The request outlines a well-defined scope:

• Plugin download/cloning
• Unpacking to temp directories
• Parsing plugin.json to create SDK configuration entries

I've labeled this as enhancement. This would be a cross-SDK feature affecting all language implementations, so the team will need to coordinate implementation across .NET, Go, Node.js, and Python SDKs.

AI generated by Issue Triage Agent

[SteveSandersonMS]

@MattKotsenas Interesting suggestion - thanks! We think maybe rather than a plugin installer (as in, something that registers marketplaces and performs downloads) what we'd want to expose is the ability to consume directories of skills, hooks, etc that the application provides. Do you think that would meet your needs?

[MattKotsenas]

I think that's fine if it's of the form: here's a top level directory, use the CLI's algorithm to resolve each of those extension types.

That's in contrast to what I have to do today, which is do the traversal myself and parse plugin.json to extract metadata.

I think deferring the plugin download to the host is reasonable.

Does this make sense?

[MattKotsenas]

Today each extension is a separate top level type, so if a plugin includes multiple types (e.g. skills and an MCP) I have to walk the plugin for myself

[RDalziel]

+1 here. From my perspective i'm looking to leverage MCPs as a convenient way to distribute shared knowledge/skills via a central SDK Runner. MCPs have a useful mechanism where each run it'll pick up the latest MCP version via NPX so the providers of the MCP just need to push new updates for it to be picked up.

If the Plugins did the installs too then it'd be a nice way for them to stay up to date without needing to update the SDK App every time. Having the skills etc in a local directory would maybe require too much ownership on the SDK side for me (Assuming i'm following this correctly!)

[plusplusoneplusplus]

+1

[MattKotsenas]

I see that CLI 0.0.421 supports a --plugin-dir option now. So I think this request basically becomes a request to plumb that option into the SDK.

[SteveSandersonMS]

@MattKotsenas Does it already work in the way you want if you pass --plugin-dir in the cliArgs property of CopilotClient construction options? Is you request simply to elevate this to a more first-class option, or are you looking for some other change in behavior?

[MattKotsenas]

Let me check

[MattKotsenas]

@SteveSandersonMS, if there was a SessionConfig.PluginDirectories, that would mostly meet my needs.

However, while experimenting, I did notice one problem that'll hit the SDK more than the CLI. The --plugin-dir only looks for plugin.json at the root, not inside the .claude-plugin folder. That means plugins that the CLI loads just fine today via other means won't work with the dir option (and thus wouldn't work with the SDK).

Is that something that can be addressed at the same time as this?

[yuwzho]

+1

[DonJayamanne]

@SteveSandersonMS We too would like to have a SessionConfig.PluginDirectories