[BUG] Enterprise-managed marketplaces in project enabledPlugins are orphaned on first run; only install after a restart

Status Closed — not planned
Reported on v2.1.158
Maintainer reply None cached
Activity 6 comments · opened Jun 1, 2026 · closed Jul 6, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

On a fresh Claude Code install, plugins listed in a project's .claude/settings.json enabledPlugins that come from marketplaces delivered via remote managed settings (enterprise "allowed marketplace list") do not install on first launch. They only appear after one or more restarts. Root cause appears to be an ordering/race: the authorizing policy is fetched after authentication, and the in-process plugin reconcile runs before that policy + marketplace registration exist, then never completes in-process.

Environment

  • Version: 2.1.158 at launch, auto-updated to 2.1.159 mid-session
  • Platform: Linux (amzn2023)
  • Auth: Anthropic OAuth, enterprise remote managed settings in use
  • Project .claude/settings.json referenced plugins from xxxx-dev / xxxx2-product marketplaces (both delivered via the org's allowed-marketplace policy)

Observed sequence (from ~/.claude/debug/<session>.txt)

  1. First launch (PID A, v2.1.158): installed_plugins.json absent; no company marketplaces registered yet. enabledPlugins entries skipped:
  • Skipping orphaned enabledPlugins entry infra-provisioning@xxxx-dev: marketplace not registered
  • Found 0 plugins (0 enabled, 0 disabled)
  1. After auth, the policy arrives — but the first background install pass already ran:
  • Remote settings: Refreshed after auth change / Programmatic settings change notification for policySettings
  • First performBackgroundPluginInstallations → not found in any marketplace, skipping → Saved 0 installed plugins
  1. Concurrent auto-update to 2.1.159 + relaunch (PID B). Plugin load races the allowlist:
  • Plugin not available for MCP: …@xxxx-dev - error type: marketplace-blocked-by-policy
  • Plugin loading errors: Marketplace 'xxxx-dev' is not in the allowed marketplace list
  • …then git clone … succeeded → Added marketplace source: xxxx-dev (registered, but still Loaded 0 installed plugins this process)
  1. Next relaunch (PID C): now policy cached + marketplaces registered → Saved 3 installed plugins / Sync completed: 3 added. Plugins finally work.

Expected

After the post-auth remote-settings refresh adds newly-allowed marketplaces, the plugin reconcile should complete in-process and install the enabledPlugins, without requiring a restart.

Actual

enabledPlugins referencing policy-gated marketplaces are orphaned on first run and only resolve after restart(s), because (a) the allowed-marketplace policy is fetched only post-auth and (b) the install pass that runs before/around that doesn't re-reconcile to completion (visible "blocked-by-policy" race even in the post-update process).

Impact

Confusing first-run onboarding for enterprise users with managed marketplaces — plugins/skills silently absent until an unprompted restart.

What Should Happen?

The marketplaces and the plugins are installed without a CC restart.

Error Messages/Logs

Steps to Reproduce

  1. Start from a clean Claude Code install (no ~/.claude/plugins/installed_plugins.json, no private marketplaces in known_marketplaces.json).
  2. Open a project whose .claude/settings.json lists enabledPlugins from a marketplace that is delivered/authorized via enterprise remote managed settings (not yet registered locally), e.g.:

"enabledPlugins": {
"plugin-a@org-dev": true,
"plugin-b@org-product": true
}

  1. Launch Claude Code and complete first-run onboarding + authentication.
  2. After login, open /plugin (or check installed_plugins.json).
  • Result: No plugins installed. Debug log shows Skipping orphaned enabledPlugins entry … : marketplace not registered and Found 0 plugins, even though the post-auth Remote settings: Refreshed after auth

change has fired and authorized those marketplaces.

  1. Restart Claude Code (once or twice).
  • Result: Marketplaces register and plugins install (Saved N installed plugins).

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.159 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

uname -a
Linux ip-10-40-243-81.eu-west-1.compute.internal 6.12.88-119.157.amzn2023.x86_64 #1 SMP PREEMPT_DYNAMIC Wed May 20 06:36:23 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

View original on GitHub ↗

5 Comments

github-actions[bot] · 4 months ago

Found 2 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/63028
  2. https://github.com/anthropics/claude-code/issues/51118

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

abhinas90 · 4 months ago

Thanks for the detailed report, @harley84. This looks like a process lifecycle issue rather than a one-off crash — these tend to cascade across multiple sessions once they start.

Quick diagnostic matrix to narrow it down:

  1. Check for orphaned Claude processes: Run ps aux | grep -i claude | grep -v grep during the next hang. If you see child processes without a parent session, the agent spawner isn't cleaning up on session close.
  1. Memory baseline: Before your next long session, run ps -o pid,rss,comm -p $(pgrep -f claude) to get a baseline RSS. Check again after 30 min of heavy tool use. A steady increase without plateau = leak.
  1. Session boundary stress test: Open 3 sequential sessions (close each before opening the next). If cumulative memory grows across sessions without releasing, the process manager isn't freeing on session teardown.
  1. Log correlation: Check ~/.claude/logs/ for any SIGKILL or OOM-killer messages in dmesg (dmesg | grep -i oom). If the kernel is killing it, you need a swap file or process limit.

If you want a structured hardening playbook for this (process limits, watchdog scripts, memory caps), happy to share what worked on our multi-agent deployment — we hit this exact pattern on a VPS running 4 concurrent Claude Code agents. It's almost always #1 (orphan cleanup) or #3 (session teardown).

harley84 · 4 months ago

Cross-linking related issues for triage — I don't think this is an exact duplicate of either candidate, but it shares mechanism with one and surface with the other.

Closest on mechanism: #63028. Same race shape — plugin reconciliation/attachment runs at session start before the marketplaces are available, the initial pass finds nothing, and there's no in-process re-reconcile when they do become available, so it only resolves in a fresh session. The "restart fixes it, no process restart within the session" behavior matches.

Two differences from #63028:

  • Surface: #63028 reproduces on Claude Code on the web (cloud sessions); this reproduces on the local CLI (Linux / Amazon Linux 2023).
  • Late dependency / trigger: in #63028 the thing that arrives late is the async marketplace clone. Here it's the enterprise authorization policy — the allowed-marketplace list is only fetched after OAuth authentication completes, so reconciliation runs against an empty/unauthorized marketplace set:

``
Skipping orphaned enabledPlugins entry … marketplace not registered
performBackgroundPluginInstallations → not found in any marketplace, skipping → Saved 0 installed plugins
# …auth completes, policy arrives, but the install pass already finished
# next relaunch:
Marketplace 'xxxx-dev' is not in the allowed marketplace list
# relaunch after policy is cached:
Saved 3 installed plugins / Sync completed: 3 added
``

Adjacent but distinct: #51118. Same area (enabledPlugins via managed settings, installed_plugins.json not written), but that one is a persistent failure — cache populated, entry never written, restart doesn't help, only a manual installed_plugins.json edit fixes it. This issue self-heals on restart once the auth policy is cached, so the root cause is different (an ordering race, not a missing registration step).

The part neither issue covers is the auth-policy fetch ordering on the local CLI: the fix here would be to re-run plugin reconciliation in-process after the post-auth remote-settings refresh authorizes new marketplaces, rather than requiring a relaunch.

To be clear on scope: this is a plugin-reconciliation ordering issue (resolves on restart), not a process-lifecycle or memory problem — restart consistently fixes it, which rules out a leak/orphan-process cause.

github-actions[bot] · 3 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

harley84 · 1 month ago

Still relevant

Showing cached comments. Read the full discussion on GitHub ↗