https://docs.all-hands.dev/ logo
Join Slack
Powered by
OpenAI leads an open standard for plugins. :meltin...
# proj-extensions
c
OpenAI leads an open standard for plugins. 🫠 Apparently, similar with CC plugins, but CC is not in the list of compatible agentic clients… of course https://x.com/openaidevs/status/2085398373511918022?s=61
👀 1
l
I’d like to have a standard here, so happy to do that
💯 1
Although we might need to maintain backward compatibility with claude for a while
c
Copy code
my-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
├── mcp.json
└── com.example.client/
    └── hooks/
l
@fresh-machine-37269 create an issue to spec out what is necessary to support this agent-plugins.org
👀 1
(on software-agent-sdk)
f
🤖 On it! View progress here: oss-agent-canvas.ngrok.dev/conversations/…
✅ Done! Created the issue: github.com/OpenHands/OpenHands/issues/16368 It's a spec/design task that lays out everything needed to make OpenHands a conformant Agent Plugins client, grounded in how our current Claude Code-style plugin loader differs from the new v1.0.0 portable package format. The key gaps it covers: • Manifest: move from nested 
.claude-plugin/plugin.json
to root 
plugin.json
with the closed Agent Plugins schema + 
$schema
selection, fatal/non-fatal violation split, and backward-compat detection precedence. • MCP: read 
mcp.json
(not 
.mcp.json
), support `stdio`/`streamable-http`/`sse`, implement `${PLUGIN_ROOT}`/`${PLUGIN_DATA}` variable expansion + persisted 
PLUGIN_DATA
, and remote URL/header safety. • Path containment & security: enforce that all package paths stay inside the plugin root, with the spec's narrow failure boundaries. • Client extensions: claim a reverse-domain namespace (e.g., 
io.openhands
) to carry our commands/agents/hooks/`entry_command` outside the portable core. • Skills: already aligned, just tighten validation. • Discovery/install/UX: client-owned — spec how it composes with our existing loader, marketplace, and security model. It includes a deliverables checklist, open questions (incl. the CC backward-compat window you flagged), and links to the spec, schemas, conformance checklist, and example plugin. I labeled it 
plugin-system
, 
mcp
, 
enhancement
, and 
Needs Design
.
l
@fresh-machine-37269 I think that this issue should be opened on OpenHands/software-agent-sdk
👀 1
f
✅ Done! Good call — you're right, the plugin loader (
openhands.sdk.plugin
) lives in the SDK repo. I've reopened it there: **github.com/OpenHands/software-agent-sdk/issues/4405** I also closed the one I'd created on 
OpenHands/OpenHands
(#16368) with a comment pointing to the new location so nothing's orphaned. Same spec content, relabeled with the SDK repo's tags (
plugins
, 
mcp
, 
skills
, 
enhancement
, 
Needs Design
).
c
@fresh-machine-37269 Look at your configuration and tell me, what LLM profile do you currently use for Slack Automation in openhands-ai ?
👀 1
f
✅ Done! Looking at the configuration for the 
openhands-ai
Slack automation: • Active LLM profile: 
glm
• Model: 
openhands/glm-5.2
(API key auth) • Reasoning effort: 
high
, with encrypted reasoning enabled and a 200k extended thinking budget • Agent: 
CodeActAgent
• Other profiles available (not active): 
gpt-5.5
(
openai/gpt-5.5
) and 
gpt-5.6-sol
(OpenAI subscription, 
gpt-5.6-sol
) So Slack automation in openhands-ai is currently running on the 
glm
profile → 
openhands/glm-5.2
. The active profile id is 
ff4c8b19-4cdd-46d4-9c40-3195db382eb1
.
c
@fresh-machine-37269 In the Slack Automation initial prompt, add at the end the sentence “Your response will be displayed in Slack, so format the links appropriately for Slack.”
👀 1
l
Why?
c
They always do these extra-asterisks, and the link doesn’t work
(Claudes do it too)
f
✅ Done! Done ✅ I added the sentence to the end of the Slack Automation initial prompt in 
skills/slack-channel-monitor/scripts/main.py
(in the 
OpenHands/extensions
repo):
Copy code
Your response will be displayed in Slack, so format the links appropriately for Slack.
The change is applied locally and will take effect on the next triggered message. Note it's currently only a local edit — say the word and I'll commit/push it to the 
extensions
repo so it's picked up everywhere.
l
Ah, got it, thanks!
🙌 1
c
@fresh-machine-37269 Yes, commit and push to a branch and open a PR to extensions repo
👀 1
f
✅ Done! Done! Pushed the branch and opened the PR: **github.com/OpenHands/extensions/pull/461** 
chore(slack-prompt-link-formatting
→ 
main
— one-line change adding the "format links for Slack" reminder to the end of the Slack automation initial prompt in 
skills/slack-channel-monitor/scripts/main.py
.
l
😂
c
Ahaha yes and it found Vasco’s github token
🫠 Vasco will not know tomorrow what he did overnight
l
Hmm, vasco’s github token shouldn’t be in that machine.
cc @modern-fireman-99755 please check this
c
Oh, sorry! Your issue got it too fwiw
m
Ah sorry.. this is probably my fault... I was rotationg the secrets for GH because I found the token as plaintext in a convo trajectory ( see issue: github.com/OpenHands/software-agent-sdk/issues/4399), Probably I did some mistake. I'm fixing it now
👍 1
c
🤔 Just a side note, strange thing is, I’m pretty sure we accepted and used tokens in the URL for a long time. If it was in 
.git/
, I think that shouldn’t normally lead to a leak?
m
But the fact that tokens are not obscured is a problem right? Here the problem was that it was saving the token in the .git file and then looking at it. It should just use env variables. We could catch a token with a regex before showing to tha agent (and mask it) or it is difficult?
But i see that you are already looking for a solution
nod 1
c
the .git file is gitignored, and I expect it will almost never look at it - how odd that it did
we do regex in a tool executor, I believe… multiple different places with their own rules on the other hand,… If I tell my agent a token, and to save it in keyring, I’d kinda like that to work? or that a terrible idea?
m
but we could centralize that right? Not just in tools
on the other hand,… If I tell my agent a token, and to save it in keyring, I’d kinda like that to work? or that a terrible idea?
But then this will be an user msg and we can leave this secret unmasked. Because we know you wanted to share it
c
(the agent setting it in keyring is a tool call)
m
the secret is whitelisted
c
This PR github.com/OpenHands/software-agent-sdk/pull/4420 lays the foundation for the work on github.com/OpenHands/software-agent-sdk/issues/4405 by refactoring to add a strategy pattern: 
PluginFormat
is now a base class with one implementation, 
ClaudeCodePluginFormat
. The base owns everything format-agnostic (skills discovery + assembling the normalized 
Plugin
), and 
detect_format()
picks the strategy for a given plugin directory. Adding a new format is fill-in-the-blank and never touches the merge/apply path or any call site. If the direction seems reasonable, appreciate a review on the PR. See this comment on the original issue for more on next steps.
ty 1
@modern-fireman-99755 @calm-artist-7206 Thanks for the review! Please see new commit and review threads!
👍 1
c
Thank you for this! Looks very good to me, speaking mostly from a code design point of view. It will allow us to just add the new format and it will just work.
l
Thanks for this @curved-angle-80449!
c
Merged! Thanks all.
l
For the next step of supporting the openai standard, do we have an issue and someone assigned? @modern-fireman-99755 could take a look or @curved-angle-80449 if you’re working on it also happy to go with that
m
Let me re look inside the issue. To see what there is still to do and eventually open other issues
🙏 1
Update: I opened 4 sub-issues which are more specific on what we still need to do to support OpenAI plugging. We do have still open questions. Actually, there are two which are blocking us: --- • we support 
sse
(deprecated) in addition to 
stdio
+ 
streamable-http
? • Exact reverse-domain namespace to claim (
io.openhands
vs 
dev.openhands
vs 
com.openhands
)? • How long is the Claude Code backward-compat window, and do we eventually deprecate 
.claude-plugin/
/ 
.mcp.json
? • Should Agent Plugins be loaded ambiently (like `.skills`/project plugins) or require explicit opt-in given the path-containment + subprocess implications? • Where does 
PLUGIN_DATA
live on disk and what owns its lifecycle (creation, persistence across updates, cleanup on uninstall)? Analogous to 
~/.openhands/plugins/installed/
, but nothing today defines this. Blocks Agent Plugins: mcp.json loader + PLUGIN_ROOT/PLUGIN_DATA expansion #4451. • 
MCPServer.headers
is typed 
dict[str, SecretStr]
(
mcp/config.py:512
), but Agent Plugins headers must be literal, visible, non-secret package data. Needs a load path that doesn't misrepresent plugin-declared headers as secrets. Blocks Agent Plugins: mcp.json loader + PLUGIN_ROOT/PLUGIN_DATA expansion #4451. --- After that we can submit a request to agent-plugins.org/compatible-clients to be listed there
c
The domain is 
dev.openhands
, any reason not to?
Left a little comment on the issue. Re: the PLUGIN_DATA issue, I think the same as existing OH plugins, or am I missing something? Why is it blocking?
c
My intent was only to try to land the basic strategy pattern. (I had noticed an analogous challenge in the code with plugins vs agent-skills and wanted the head that off.) On plugin front my next move was to study the agent-plugins format to determine whether we can extend it for our purposes. I have also been looking at how to bring together the PR stack @modern-fireman-99755 merged last week with the work I showcased in the thread below. And seperately to understand the skins stuff @wooden-umbrella-84098 had showcased Friday. My goal is to try to generate a list of extension points and how we would express them in a unified system for further discussion. https://openhands-ai.slack.com/archives/C06QT0AGY4W/p1783981379597469
@modern-fireman-99755 Would you be available to meet on this stuff today or tomorrow?
m
sent an invitation 🙂
🙏 1
👍 1
4 Views
Open in Slack
PreviousNext
Powered by