[BUG] Plugin `dependencies` never resolve when the desktop app loads plugins via `--plugin-dir` (re-report of #72925 which was wrongly closed as dup of unrelated #72025)

Preflight Checklist

• [x] I have searched existing issues. This is a re-report of #72925, which was auto-closed by github-actions as a duplicate of #72025 — but #72025 is a different bug ("plugin hooks and slash commands are not executed in the Desktop app," i.e. plugin loading itself never runs). The loader behavior described here (dependencies fail to resolve in --plugin-dir mode) is not covered by #72025, #70655, or #63174 (verified individually). Reopening #72925 would also be fine; I'm filing a fresh issue for visibility.
• [x] This is a single bug report.
• [x] Reproduced on the latest Claude Code available in each affected surface.

What's Wrong?

When Claude Code loads a plugin via --plugin-dir <installPath>, the plugin's ID is registered as <name>@inline. Dependency resolution is done by exact marketplace-qualified ID match, so a dependencies entry that names any specific marketplace (whether the concatenated-string form "pr-review-toolkit@claude-plugins-official" or the documented object form { "name": "pr-review-toolkit", "marketplace": "claude-plugins-official" }) will look for <name>@<marketplace> and fail to find <name>@inline. The declaring plugin is then disabled with dependency-unsatisfied — silently, with no user-visible error. The plugin's skills, agents, and hooks simply do not appear.

The Claude Code desktop app spawns its bundled CLI and passes every enabled plugin as an explicit --plugin-dir <path>, so every published plugin that uses dependencies is broken in the desktop app while working fine in the terminal CLI. Plugin authors who dev-loop from the terminal (the recommended workflow) will not catch this before release.

There is no dependencies form that works in both environments today:

| dependencies form | Terminal CLI (installed) | Desktop app (--plugin-dir inline) |
|---|---|---|
| Bare string "pr-review-toolkit" — docs say "resolves within the same marketplace as the declaring plugin" | Fails (declaring plugin's marketplace does not host pr-review-toolkit) | Loads (both inline, @inline matches @inline) |
| Object { "name": "pr-review-toolkit", "marketplace": "claude-plugins-official" } | Loads | Fails (@inline ≠ @claude-plugins-official) |
| No dependencies field | Loads | Loads |

The only shipping-safe option is to omit dependencies entirely and instruct users to install the required plugins separately — which defeats the purpose of the field.

What Should Happen?

The plugin should load in the desktop app the same way it loads in the terminal CLI, and its declared dependencies should resolve to whatever installed/enabled copy of the dependency the user has. Suggested fixes, any one is sufficient (borrowed from and consistent with #72925's suggestions):

1. Resolve dependencies by bare name across all loaded plugins when the requested marketplace matches an inline-loaded plugin's original source, or fall back to name-only matching if no marketplace-qualified match is found among enabled plugins in the session.
2. Have the desktop invoke the CLI without collapsing plugin IDs to @inline — for example by leaving installed_plugins.json intact and using the same loading path as the terminal CLI.
3. At minimum, surface the load failure as a user-visible warning naming the plugin and the missing dependency, rather than silent no-op. Today the failure is only visible via --debug --debug-to-stderr.

Error Messages/Logs

Plugin not available for MCP: ccd-flowkit@inline - error type: dependency-unsatisfied
Plugin loading errors: Dependency "pr-review-toolkit@claude-plugins-official" is not installed

Same error class as #72925 reported for pstack@inline.

Steps to Reproduce

Two independent reproducers exist:

Reproducer A: michael-denyer/pstack-claude at commit 54d6617 (from #72925, macOS)

git clone https://github.com/michael-denyer/pstack-claude && cd pstack-claude && git checkout 54d6617
claude --debug --debug-to-stderr --setting-sources "" --settings '{}' \
  --plugin-dir "$PWD/plugins/pstack" -p 'ok' 2>&1 | grep -i dependenc

Reproduces dependency-unsatisfied. Deleting the dependencies key and rerunning loads 44 skills and 1 agent.

Reproducer B: shiyu9/ccd-flowkit-dev tag v0.2.1 (Windows desktop app, tested by an end-user)

1. Install pr-review-toolkit@claude-plugins-official and security-guidance@claude-plugins-official from the official marketplace.
2. Install ccd-flowkit@shiyu9/ccd-flowkit at v0.2.1. v0.2.1's plugin.json declares dependencies in the object form:

``json
"dependencies": [
{ "name": "pr-review-toolkit", "marketplace": "claude-plugins-official" },
{ "name": "security-guidance", "marketplace": "claude-plugins-official" }
]
`
with allowCrossMarketplaceDependenciesOn: ["claude-plugins-official"]` in the root marketplace (as required by plugin-dependencies docs).

1. Open Claude Code desktop app. Observe: the plugin's 2 skills, 24 agents, and hooks are not registered. /ccd-flowkit:run is not offered.
2. Open the terminal CLI in the same project. Observe: the plugin loads and /ccd-flowkit:run works.

Both the concatenated string form (v0.2.0) and the object form (v0.2.1) reproduce the failure in the desktop app. Removing dependencies entirely (v0.2.2) fixes it. Full triage in shiyu9/ccd-flowkit#1, fix in shiyu9/ccd-flowkit-dev#78.

Is this a regression?

Unclear. #72925 reported the same behavior on 2026-07-01, so it has been present for at least two weeks.

Claude Code Version

Reproducer B environment:

• Desktop app (bundled CLI): 2.1.205 (Windows 11)
• Terminal CLI: 2.1.209 (Windows 11) — does not reproduce

Reproducer A / #72925 environment: 2.1.197 (macOS 15.x). Two versions and two OSes reproduce, so this is not platform- or version-specific.

Platform

Claude API (relevant surface is the desktop app's bundled CLI)

Operating System

Reproducer A: macOS 15.x. Reproducer B: Windows 11. Cross-platform.

Terminal/Shell

Reproducer A: zsh (headless -p). Reproducer B: desktop app spawned CLI (no interactive shell involved).

Additional Information

Impact is high and silent:

• Every published plugin that uses dependencies (a documented feature) is broken for every desktop app user, with no user-visible failure indication.
• The plugin's skills/agents/hooks simply don't appear; end users won't realize why.
• Plugin authors testing via the terminal CLI (the recommended dev-loop) don't catch it, so the bug ships.

Related: #72925 (same bug, wrongly auto-closed as duplicate of #72025), #9444 (feature request for plugin dependencies more broadly).

Happy to test any fix against Reproducer B.