Introducing AgentPluginFormat in sdk: github.com/OpenHands/software-agent-sdk/pull/4474 cc @curved-angle-80449 @calm-artist-7206

Correct me if i’m wrong, does the location of plugin data mean where are plugins located on disk? if yes, we will support the same locations, I don't see why not.

I answered in the PR 🙂 I'm also new to this standard. So feel free to ask more questions if needed so I can check if I understand what is going on

I think we’re left with one, the schema variable

actually yes we have just a schema... So it is a little bit overkilling to do what I'm doing

what llm was it?

One thing that is nice about having a schema I think is that it could help us make it clear which extensions to the base format we support. For example we extend Claude Code plugins but I think you have to read a fair bit of code to see where.

Opus-5, but i was discussing with and i said i wanted that

Another thing I saw when reviewing this and looking at the open question re: PLUGIN_DATA dir issue is that we now have this--

DEFAULT_INSTALLED_PLUGINS_DIR = ~/.openhands/plugins/installed/

(

installed.py:22

), managed by

install_plugin

/

uninstall_plugin

/

enable_plugin

/

disable_plugin

. This was added for the sake of a new extension mechanism but I am not sure we have been clear about how this relates to the directory in which plugins are cached at load / resolution time. (It's a different one today.) If

DEFAULT_INSTALLED_PLUGINS_DIR

is only for new extension system perhaps we should name this differently. If it is supposed to also relate to plugins, we may have some reconciliation to do. I've also seen issues where an agent loads a plugin that contains scripts or other files and the agent can't find them because it doesn't know where to look. I don't have a recent repro case handy--can't remember if I saw this in plugin based automations or conversations started with plugin references using app server APIs... Seems like we should make some quick decisions about these dirs / lifecycle.

When you say new extension mechanism, what do you refer to?

UI extensions for agent-canvas.

Ah, thank you. I thought that was intended as UI only. Does that have anything to do with sdk plugins?

Well @limited-student-10747 had asked if it makes sense to extend Agent Plugins spec (as we had done with Claude Code for other purposes) to also support agent canvas UI extension points. We have a TODO to answer the question as to how we might do that and whether it is a good idea or whether the systems should remain separate, perhaps with a reference between them. (For example one way to do this would be to have seperate agent-canvas extensions mechanism that defines an extension point for loading Agent Plugins by reference.)

Re: issues where an agent can’t find scripts or other files We solved this in AgentSkills

invoke

by telling the agent where that skill files are, the location on disk. A single sentence. … That was the

invoke

tool… but maybe it doesn’t need to be different?

Working on a concrete proposal for PLUGIN_DATA which I'll add as a comment to #4405...

@calm-artist-7206 I fixed the thing with the schema

One thought: whatever we do in canvas, it interacts with agent-server via its endpoints. So I don’t know what it could mean to be “related”, what the canvas addon does is a client call

I’d like to use “extension” as the umbrella term, and ideally call all other things some other name

The initial Devin proposal for UI termed them “addons”. I like it precisely for that reason

Devin and Vasco wanted to persist some stuff in the agent server side for installed plugins

This is for control-version in the case of UI components

Do you mean like • I have a Jira custom interface as canvas addon • it works with a Jira SDK plugin • but only versions 1.26+ ?

I think generally that seems right, we have so many versions that I'm not sure which version you're referring to though

No, it’s just an example. I’m trying to understand what behavior seemed to imply that canvas addons would reach into the sdk. I think this one doesn’t, it’s just a version dependency