Question on plugin marketplace roadmap: when will marketplace-installed plugins load executable entries?

[uos1231234]

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):

1. step/plugins.ts L4-8 header says the built-in marketplace has a "deliberately smaller contract" and "this module owns discovery and provisioning only".
2. L645-646: a manifest with entry yields "Executable plugin entries are recorded but not loaded by the Step marketplace facade." So a marketplace-installed plugin can never load executable code today.
3. core/resource-loader.ts sources commands only from extension.commands (L752); its skill discovery roots (~/.stepcode/agent/skills, <cwd>/.stepcode/skills, ~/.agents/skills, settings skills) do not include ~/.stepcode/plugins/.... Verified locally: /plugin marketplace add + /plugin install succeeds and files land in ~/.stepcode/plugins/<name>/, but the plugin's commands never appear in the palette — /reload and a full process restart don't change it.
4. step/mcp.ts L231-232 skips string mcpServers declarations; only inline objects are started.

Net effect: for marketplace-installed plugins, the only thing that runs is an inline mcpServers process. entry is recorded-but-not-loaded; commands/skills/agents are parsed and validated but never registered.

Questions:

1. Any timeline for letting marketplace-installed plugins load an executable 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.
2. Any plan to wire manifest skills/commands/agents into the resource loader, so declarative marketplace plugins become slash commands / skills?
3. We noticed agent-core/src/harness/agent-harness.ts has this.hooks = new UnavailableRegistry("hooks.on", ...), and config/src/migrations.ts states "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.
4. Minor: marketplace entries with an object source are skipped ("this runtime cannot fetch"), and string sources must resolve inside the checkout. Any plan to support remote owner/repo entries, 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.

[xuxujo97-coder]

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:631 emits "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.

[Uking-xxx]

#204 addresses part of this issue:

• Q2 (skills / commands): a plugin's skills and commands are now loaded through the resources_discover channel. 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. agents is not wired in yet.
• Finding 4 (string mcpServers): the string form pointing at a sibling .mcp.json is now resolved. It also supports url-only remote servers, the headers spelling with ${VAR:-fallback} interpolation, and step 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.mjs work.

Q1 (executable entry), Q3 (lifecycle hooks) and Q4 (remote owner/repo sources) 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.

[uos1231234]

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 install path 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/repo sources land, it removes a manual step for us; if not, we keep the pre-seeded checkout. Either way we're fine.