Repository navigation
Question on plugin marketplace roadmap: when will marketplace-installed plugins load executable entries? #196
Description
Activity
This comment was generated by AI during triage.
Thanks — the line references made verification direct.
Verification (against current
main)- Your reading is correct:
packages/coding-agent/src/step/plugins.ts:631emits "Executable plugin entries are recorded but not loaded by the Step marketplace facade." (line drifted slightly from your 09-24 snapshot), and the module header scopes itself to discovery and provisioning — marketplace-installed plugins indeed cannot load executable code today.
When marketplace entries will gain an executable load path is a roadmap call; routed to the maintainers.
- Your reading is correct:
#204 addresses part of this issue:
- Q2 (skills / commands): a plugin's
skillsandcommandsare now loaded through theresources_discoverchannel. A plugin installed during a session takes effect on the next/reload, with no restart needed. Project-level plugins are only loaded once the project is trusted.agentsis not wired in yet. - Finding 4 (string
mcpServers): the string form pointing at a sibling.mcp.jsonis now resolved. It also supports url-only remote servers, theheadersspelling with${VAR:-fallback}interpolation, andstep mcp login <bare name>. - Also fixed along the way: plugin stdio MCP servers now run from the plugin root, so relative paths like
node server/index.mjswork.
Q1 (executable
entry), Q3 (lifecycle hooks) and Q4 (remoteowner/reposources) are roadmap decisions that #204 doesn't touch. We'll leave this issue open for tracking; if you'd find it easier to follow them as separate issues, we can split them out.- Q2 (skills / commands): a plugin's
Thanks — Q2 being in #204 is good news for us, and I have nothing to add to the four MCP drops.
On splitting: I'd rather not open separate issues. Q1/Q3 aren't a blocker for us — the
step installpath is complete for what we do, and our README already documents the current contract, so there is no user confusion to fix. Splitting would mostly create tracking debt on our side for a roadmap decision that is yours to make.Q4 is the one I'd leave open to you: if remote
owner/reposources land, it removes a manual step for us; if not, we keep the pre-seeded checkout. Either way we're fine.Reacted by Uking-xxxThanks for the detailed feedback and for following up!
We've addressed plugin
skillsandcommandsloading, along with several MCP configuration compatibility issues, in PR #204.The remaining capabilities, including executable
entryloading, lifecycle hooks, and remoteowner/reposources, are still under consideration for future development.We'll keep this issue open to track these improvements. Thanks again for your contributions and support!
Hi Step Code team,
We've been building Step Code plugins and testing against v0.1.1. We ran into what looks like a deliberate design boundary rather than a bug, and we'd like to confirm our reading and ask about the roadmap. Line references are against a 2026-09-24 snapshot of
main.What we verified (source + local TUI):
step/plugins.tsL4-8 header says the built-in marketplace has a "deliberately smaller contract" and "this module owns discovery and provisioning only".entryyields "Executable plugin entries are recorded but not loaded by the Step marketplace facade." So a marketplace-installed plugin can never load executable code today.core/resource-loader.tssources commands only fromextension.commands(L752); its skill discovery roots (~/.stepcode/agent/skills,<cwd>/.stepcode/skills,~/.agents/skills, settingsskills) do not include~/.stepcode/plugins/.... Verified locally:/plugin marketplace add+/plugin installsucceeds and files land in~/.stepcode/plugins/<name>/, but the plugin's commands never appear in the palette —/reloadand a full process restart don't change it.step/mcp.tsL231-232 skips stringmcpServersdeclarations; only inline objects are started.Net effect: for marketplace-installed plugins, the only thing that runs is an inline
mcpServersprocess.entryis recorded-but-not-loaded;commands/skills/agentsare parsed and validated but never registered.Questions:
entry(or bridging the marketplace and extensions channels)? This is the single blocker for "install from a marketplace and it just works" for extension-shaped plugins.skills/commands/agentsinto the resource loader, so declarative marketplace plugins become slash commands / skills?agent-core/src/harness/agent-harness.tshasthis.hooks = new UnavailableRegistry("hooks.on", ...), andconfig/src/migrations.tsstates "Hooks have been renamed to extensions." Is a lifecycle-event mechanism (equivalent to the extensions'pi.on("turn_end" / "session_before_compact" / "tool_result")) on the roadmap for marketplace plugins? Our use case must act right before compaction; extensions can do that today, marketplace-delivered ones cannot.sourceare skipped ("this runtime cannot fetch"), and string sources must resolve inside the checkout. Any plan to support remoteowner/repoentries, so plugin authors can keep code in their own repo and just be indexed?Context: we published a context-archive extension (MIT) at https://github.com/uos1231234/step-context-archive, with a declarative copy pending in a community marketplace PR. Happy to help test any of the above. If 1-3 are out of scope for now, we'll document the current contract in our README so users aren't surprised.
Thanks for the great work on Step Code.