[BUG] Enterprise-managed marketplaces in project enabledPlugins are orphaned on first run; only install after a restart
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)
- 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)
- 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
- 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)
- 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
- Start from a clean Claude Code install (no ~/.claude/plugins/installed_plugins.json, no private marketplaces in known_marketplaces.json).
- 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
}
- Launch Claude Code and complete first-run onboarding + authentication.
- 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.
- 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
Showing cached comments. Read the full discussion on GitHub ↗
5 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
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:
ps aux | grep -i claude | grep -v grepduring the next hang. If you see child processes without a parent session, the agent spawner isn't cleaning up on session close.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.~/.claude/logs/for anySIGKILLor OOM-killer messages indmesg(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).
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:
``
``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 (
enabledPluginsvia managed settings,installed_plugins.jsonnot written), but that one is a persistent failure — cache populated, entry never written, restart doesn't help, only a manualinstalled_plugins.jsonedit 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.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
Still relevant