[BUG] Org-plugin "Installed by Default" plugins missing from a fresh Claude Code on the web session — related to #63028?
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
Original symptom:
Admin console confirmed all 7 plugins showing Installed by default, with recent "Last updated" timestamps (e.g. wdi-asana updated same-day).
A Claude Code on the web session opened before a marketplace update showed all 7 plugins enabled.
A new session opened by the same user after that update, same day, showed zero org plugins — despite the admin console showing them all installed-by-default at check time.
We initially assumed this was anthropics/claude-code#63028 (marketplace-clone-races-skill-attachment) recurring against the admin-console path. Since then we've isolated something more specific, which we think narrows down where the bug actually lives.
What we tested and confirmed (client-side), ruling out any workaround on our end:
We built an org-shared cloud environment ("wdi-standard") with a Setup script that runs claude plugin marketplace add WDI-GIS/claude-plugins followed by claude plugin install <name>@wdi-claude-plugins --scope user for each published plugin.
In a genuinely fresh session in that environment, the setup script completed (reported success in the provisioning checklist), but ~/.claude/plugins/marketplaces/ came back empty and ~/.claude/plugins/installed_plugins.json showed {"plugins": {}}. The plugin's slash command (/wdi-standards:standup-report) returned Unknown command.
Manually re-running claude plugin marketplace add WDI-GIS/claude-plugins in that same session (already launched, not headless) failed with:
× Failed to add marketplace: Failed to clone marketplace repository: HTTPS authentication failed. Please ensure your credential helper is configured (e.g., gh auth login).
Original error: Cloning into '/root/.claude/plugins/marketplaces/WDI-GIS-claude-plugins'...
fatal: could not read Username for 'https://github.com': terminal prompts disabled
A plain git clone https://github.com/WDI-GIS/claude-plugins.git (bypassing the claude plugin subcommand entirely) failed identically in that same session.
We confirmed the only mechanism that does let a live session reach an arbitrary private repo — asking Claude to work with a repo it wasn't started with — goes through an interactively-approved grant (an add_repo-style tool call gated on explicit user approval). That mechanism cannot fire from a SessionStart hook or a Setup script; both are headless, with no human present to approve anything.
Our conclusion: a session only gets authenticated git access to WDI-GIS/claude-plugins if it was created with that repo already attached as a source (or the user interactively approves adding it mid-session). There is no unattended path — from a Setup script, a SessionStart hook, or otherwise — to grant a session credentialed access to an additional private repo. This is presumably a deliberate security boundary, not a bug, in the parts we tested.
What we're asking:
Does the server-side "Installed by Default" org-plugin installer use the same credentialed git-clone path we just tested, or a separate, privileged service-level mechanism (e.g., via the GitHub App installation at the org level) that shouldn't be affected by per-session repo attachment at all?
If it's the latter, why would a fresh session miss the plugins at all, given the admin console already shows them installed-by-default? Is this genuinely a race (per #63028), or something else in the default-install sync?
If it's actually closer to the former (some shared code path with per-session credential scoping), that would mean any org using a private marketplace repo is exposed to this gap indefinitely unless the marketplace is public — which is a significant limitation worth documenting explicitly, since nothing in the plugin/marketplace docs currently mentions it.
Is there a supported way to grant a Setup script or SessionStart hook scoped, non-interactive credentialed access to a specific org-owned private repo, short of making it public? If not today, is it planned?
Happy to provide session IDs, environment IDs, and exact timestamps on request.
Org Plugin Settings:
<img width="749" height="393" alt="Image" src="https://github.com/user-attachments/assets/35703b02-0883-479a-96be-86830913fd8b" />
Snip of our marketplace.json in the WDI-GIS/claude-plugins private repo:
<img width="1526" height="791" alt="Image" src="https://github.com/user-attachments/assets/e32640f9-bc2f-4731-9646-14a7963d925f" />
What Should Happen?
Org plugins configured "Installed by Default" should be available in any Claude Code session started by a member of the organization, including Claude Code Cloud sessions. Or.... there should be a documented standard way to enable this behavior across the organization.
Error Messages/Logs
Steps to Reproduce
Open new Claude.ai cloud code session (web or desktop UI).
Ask about available organization plygins:
<img width="880" height="587" alt="Image" src="https://github.com/user-attachments/assets/6b6aac85-97c2-4f6a-9b12-4cfdbd1ffde3" />
Try to use any of the plugin skills and commands defined in the organization marketplace - they are not available:
<img width="890" height="762" alt="Image" src="https://github.com/user-attachments/assets/d07c7b9c-71d1-4ea6-aa10-73dd313ab698" />
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.237 (Claude Code)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
_No response_