A `dependencies` field in plugin.json silently prevents slash-command registration when the plugin is loaded via an explicit plugin path (desktop app / --plugin-dir)

Environment

• Claude Code 2.1.217 (desktop-app bundled) and 2.1.218 (standalone CLI), Windows 10 Pro 10.0.19045
• Plugin: multimodel-editorial-review v0.3.0 (github.com/lornova/multimodel-editorial-review), installed from a marketplace at user scope

Summary

A plugin whose .claude-plugin/plugin.json contains a dependencies field (e.g. [{ "name": "codex", "marketplace": "openai-codex", "version": "^1.0.0" }]) loads normally when discovered through settings (regular CLI sessions: its commands and skills register fine), but when the same plugin is loaded through an explicit plugin path — which is what the Claude Code desktop app does (plugins: [{type: "local", path: <installPath>}] SDK option), and what --plugin-dir reproduces — none of its slash commands are registered. Typing any of them yields Unknown command: /plugin-name:command and the session ends with 0 turns. No warning or error is emitted anywhere (debug logs included), which makes this very hard to diagnose: the same plugin works in CLI sessions and claude plugin details shows all its commands.

The declared dependency was installed and enabled the whole time, so this is not a failed-dependency-resolution outcome being reported; even if it were, silently dropping command registration (with the plugin's skills still loading) is not a reasonable failure mode.

Reproduction

1. Take any plugin with commands, e.g. one command file commands/hello.md, and a plugin.json with a dependencies field referencing an installed plugin from another marketplace.
2. Run: claude -p "/myplugin:hello" --plugin-dir <path-to-plugin> --setting-sources "" --max-turns 1
3. Result: Unknown command: /myplugin:hello
4. Remove the dependencies field from plugin.json, run the same command again.
5. Result: the command is found and executed.

Control: the same A/B with the openai-codex plugin (no dependencies field) works in both modes.

In the desktop app the effect is that every slash command of such a plugin is unusable ("Unknown command", 0 turns), while regular CLI sessions in the same project work — the two loading paths disagree.

Confirmed end-to-end: removing the dependencies field from the installed plugin's plugin.json and restarting the desktop app makes the same typed command work.

Expected

Either (a) dependencies has no effect on command registration when the plugin is loaded via an explicit path, or (b) if dependency resolution is attempted and fails in that mode, the plugin load should fail loudly with a diagnostic naming the plugin and the dependency, not silently skip command registration.