feat(code): add plugin marketplace support

[Johannes du Plessis (johannes117)]

deepagents-code now supports experimental plugin marketplaces with namespaced skills and MCP servers. Enable with DEEPAGENTS_CODE_EXPERIMENTAL=1.

Docs: langchain-ai/docs#4905

---

deepagents-code can now manage experimental plugin marketplaces and load installed plugins that contribute namespaced skills and MCP servers. The new plugin manager establishes the tui/modals, tui/screens, and tui/widgets UI convention, with colocated styling and focused state/content modules.

• Supports local, GitHub, Git, and marketplace JSON sources.
• Adds install, enable, disable, uninstall, and safe marketplace removal through /plugins and dcode plugin.
• Reloads plugin skills and plugin MCP configuration with /reload when experimental mode is enabled.
• Namespaces plugin skills as {plugin_id}:{skill_name} through a code-local PluginSkillsMiddleware adapter, so no SDK changes are required.

Made by Open SWE

[open-swe]

Open SWE Review found 2 potential issues.

Open in Web • View Open SWE trace

[open-swe]

Open SWE Review found 2 potential issues.

Open in Web • View Open SWE trace

[open-swe]

Open SWE Review found 1 potential issue.

Open in Web • View Open SWE trace

[open-swe]

Open SWE Review found 1 potential issue.

Open in Web • View Open SWE trace

[open-swe]

Open SWE Review found 1 potential issue.

Open in Web • View Open SWE trace

[open-swe]

Open SWE Review found 1 potential issue.

Open in Web • View Open SWE trace

[open-swe]

Open SWE Review found 1 potential issue.

Open in Web • View Open SWE trace

[github-actions]

✅ Trailer fixed. The previous warning is resolved.

[Mason Daugherty (mdrxy)]

tab works to advance tabs under plugins modal, but shift+tab doesn't - we should support for parity with all other nav in the TUI

[Mason Daugherty (mdrxy)]

think the tooltip is truncated?

[Mason Daugherty (mdrxy)]

/plugins modal should overlay other content with transparent background (following other modal conventions)

[Johannes du Plessis (johannes117)]

A few things to consider:

1. Marketplace downloads validate the supplied URL, but an HTTPS endpoint can redirect to HTTP. Should probably check final response URL and reject the download unless it still uses HTTPS.
2. Marketplace URLs may contain passwords or access tokens. Preserve the complete canonical URL wherever it is needed internally for authenticated updates, but redact credentials from every presentation surface: human-readable CLI output, JSON output intended for display, errors, logs, and marketplace details.
3. Skills with uppercase plugin or directory names appear in autocomplete but fail when invoked. Maybe we should normalize registered skill names to lowercase so discovery, autocomplete, and invocation use the same identifier format.
4. Root-level SKILL.md files are now supported by the loader, but the plugin discovery paths used by autocomplete and explicit invocation still omit them. Make those surfaces use a consistent path representation and add an end-to-end regression test for this supported layout.
5. Recursive skill discovery can follow directory symlinks outside the plugin root or around cycles. Resolve each directory before visiting it, skip resolved paths outside the plugin root, and track visited directories so one malformed plugin cannot loop indefinitely or suppress every skill for the run.
6. A corrupt or unsupported-version state file is currently treated like an absent file. The next install or enable operation can then overwrite it with empty state and permanently lose the user's configuration. Distinguish absent state from unreadable or newer state; refuse to overwrite the latter, preserve or back it up (for example, as .corrupt-<timestamp>), and report an actionable error.
7. Plugin discovery already collects warnings for invalid IDs, enabled-but-missing plugins, cache misses, and malformed manifests, but the plugin manager discards them. Surface these warnings, along with malformed marketplace-entry errors, in the Errors tab while preserving the existing graceful-degradation behavior.
8. The plugin manager's skill inventory uses a shallower scan than the runtime loader, so root-level or nested skills can be reported as 0 skills / No components discovered even though they load successfully. Reuse the loader's discovery path so the displayed inventory matches runtime behavior. This is related to item 4, but affects the manager's count and component summary.
9. A few internal load paths catch exceptions too broadly: startup can turn any plugin-skill discovery bug into an empty result, and the MCP/skill adapters convert generic type or value errors into no components. Narrow these catches to the expected data failures and isolate failures per plugin so unexpected programming errors remain visible. This should preserve the intentional outer boundaries that provide clean CLI errors, best-effort diagnostics, and nonfatal plugin loading.
10. The existing unresolved findings about plugin-provided MCP servers should be addressed before merge. Plugin configs currently enter the trusted user tier and may start declared commands without the fingerprint and approval flow used for project MCP servers, including from preload/background paths. Route every plugin MCP entry point through a centralized trust check, honor --no-mcp, and avoid starting subprocesses before an interactive session has approved them. An announcement alone would not provide the protection requested by those findings.

There are also a few design and coverage improvements worth making where practical, or tracking explicitly as follow-ups:

11. Two type boundaries still permit inconsistent data:

    • PluginInstance documents that plugin_id == "{name}@{marketplace}", but construction does not enforce it. A small PluginId value type or a post-init invariant would prevent live instances from disagreeing while retaining the existing string representation for stale or uninstalled records.
    • Separately from the typed union for a marketplace's own origin, MarketplacePluginEntry.source remains str | JsonObject even though it represents a tagged union of local, GitHub, git-subdirectory, and URL plugin sources. Parse that entry field into a typed union once so downstream code does not repeatedly reinterpret an untyped dictionary.

1. added _HttpsOnlyRedirectHandler rejecting every redirect hop that is not https. added a final response.geturl() scheme check before parsing or caching json.
2. applied redaction to presentation sources, creds are still stored locally
3. registered identifiers are now lowercased
4. tui/cli loader now passes the absolute resolved source path into load_namespaced_skills()
5. recursive walker now resolves each directory, skips anything outside source root, tracks visited directories.
6. addressed corrupt/unsupported state so no longer treated as absent
7. errors should now surface in the errors tab correctly
8. manager now uses same load_namespaced_skills path as runtime
9. narrowed catches
10. left unchanged, I think we should follow up on this one
11. added more typing, plus hard invariants

[Johannes du Plessis (johannes117)]

tab works to advance tabs under plugins modal, but shift+tab doesn't - we should support for parity with all other nav in the TUI

shift tab routed to action_previous_tab

[corridor-security]

Plugin-provided MCP server configurations are injected directly into the MCP loader across four call sites without passing through the existing trust/approval workflow, allowing a malicious or compromised plugin (installed while the EXPERIMENTAL env var is set) to auto-start arbitrary stdio MCP servers with attacker-controlled command and args, resulting in code execution under the user's account.

[Johannes du Plessis (johannes117)]

think the tooltip is truncated?

Moved outside the input box:

[corridor-security]

Plugin-provided MCP server configurations are merged and launched without the trust/fingerprint approval applied to project-level configs, allowing a malicious plugin (installed from an untrusted marketplace or Git repo) to execute arbitrary subprocess commands on the user's machine. This path is gated behind the DEEPAGENTS_CODE_EXPERIMENTAL flag, so only users who have explicitly opted into experimental features are exposed.

[Johannes du Plessis (johannes117)]

/plugins modal should overlay other content with transparent background (following other modal conventions)
fixed

[Yu Ishikawa (yu-iskw)]

Johannes du Plessis (@johannes117) This looks cool.

1. Can we use marketplace and plugins in DeepAgents in addition to dcode?
2. Is there any plan to support the marketplace and plugins in deepagentsjs? I want to use them in TypeScript as well.
3. Is there any plan to support sub agents and commands like Claude Code? I want to put markdown-based subagents to a plugin.

[Johannes du Plessis (johannes117)]

Johannes du Plessis (Johannes du Plessis (@johannes117)) This looks cool.

1. Can we use marketplace and plugins in DeepAgents in addition to dcode?
2. Is there any plan to support the marketplace and plugins in deepagentsjs? I want to use them in TypeScript as well.
3. Is there any plan to support sub agents and commands like Claude Code? I want to put markdown-based subagents to a plugin.

1. plugins are only in dcode for the moment, I don't think there are any immediate plans to support in deepagents sdk
2. similarly, since this is dcode only for the moment, I don't think it will come to js. although I'll chat to the team
3. I think we are looking into this, we want the plugin feature to be compatible with plugins from other tools etc

[Alexander Olsen (aolsenjazz)]

Yu Ishikawa (@yu-iskw) Hey Yu! To add onto what Johannes said -

We're actively looking into opportunities to support some features of plugins in deepagents. E.g. namespaces skills to power plugin skills/"skill packs".

On 1 and 3, I'd love to learn more about your use cases. We're interested is achieving parity with Claude Code for some of the plugin features, and I'd love to be able to have specific examples/stories to share with the team. Please share whatever you're comfortable with!