[BUG] Repo-committed extraKnownMarketplaces + enabledPlugins never processed in claude.ai/code cloud sandboxes (hooks from the same settings.json work)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet (closest relatives hit different links of the chain: #16870 is the managed-settings tier being ignored locally, #76759 fails after a registration already exists, #77184 concerns pruning of declared marketplaces)
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code (2.1.211)
What's Wrong?
A private repo commits this .claude/settings.json on its default branch (sanitized; the marketplace source repo is the same private repo the session runs in):
{
"extraKnownMarketplaces": {
"myteam": {
"source": { "source": "github", "repo": "myorg/myrepo" },
"autoUpdate": true
}
},
"enabledPlugins": {
"myplugin@myteam": true
},
"hooks": {
"PostToolUse": [
{
"hooks": [
{ "type": "command", "command": "python \"$CLAUDE_PROJECT_DIR/tools/hook.py\"" }
]
}
]
}
}
In a claude.ai/code cloud session on that repo (booted via claude --cloud from a local checkout of the default branch; sandbox: Linux, Claude Code 2.1.211):
- The
hookskey from this file IS honored: the PostToolUse hook fires repeatedly,$CLAUDE_PROJECT_DIRexpands, hook output is injected. So the committed file is read and trusted. - The
extraKnownMarketplaceskey is never processed:~/.claude/plugins/known_marketplaces.jsondoes not exist at any point in the session, before or after any command.~/.claude/plugins/contains only an emptyinstalled_plugins.json({"version": 2, "plugins": {}}) whose mtime predates the session (baked into the sandbox image). Nomarketplaces/directory, nocache/directory. - Consequently
enabledPluginscannot resolve: none of the plugin's skills appear in the session's skill surface, and/myplugin:...commands are unknown. claude plugin marketplace update myteaminside the sandbox fails withMarketplace 'myteam' not found. Available marketplaces:(empty list), confirming zero registered marketplaces.
The plugin docs recommend exactly this mechanism for team distribution: "Declare them in the repo's .claude/settings.json instead" (plugins/marketplace docs). Cloud sandboxes are the environment that guidance targets most (no user-scope state), and they are where the key does nothing.
A possibly related observation from a local machine (Windows 11, 2.1.211, same repo): the declared autoUpdate: true is never merged into an already-registered known_marketplaces.json entry for the same marketplace either (that entry was originally created by a manual claude plugin marketplace add). So across both surfaces I have not observed project-settings extraKnownMarketplaces ever create or modify a marketplace registration; only manual CLI registration works. If a consent gate for project-settings marketplaces cannot prompt in the cloud sandbox and silently declines instead, that would explain the cloud half; in that case the decline should be loud.
What Should Happen?
At session start in a cloud sandbox, marketplaces declared in the repo's committed .claude/settings.json should be registered and (with autoUpdate: true) fetched, and enabledPlugins should install and surface the plugin's skills. If a consent/trust gate intentionally blocks this in headless or cloud contexts, the refusal should be surfaced loudly instead of being silently skipped while sibling keys (hooks) from the same file are honored.
Error Messages/Logs
$ claude plugin marketplace update myteam; echo "exit=$?"
Updating marketplace: myteam...Failed to update marketplace(s): Marketplace 'myteam' not found. Available marketplaces:
exit=1
$ cat ~/.claude/plugins/known_marketplaces.json
cat: /root/.claude/plugins/known_marketplaces.json: No such file or directory
$ cat ~/.claude/plugins/installed_plugins.json
{
"version": 2,
"plugins": {}
}
$ ls -la ~/.claude/plugins/marketplaces/
ls: cannot access '/root/.claude/plugins/marketplaces/': No such file or directory
Steps to Reproduce
- In a private repo, commit the
.claude/settings.jsonabove on the default branch (marketplace source = the repo itself; any plugin with at least one skill; optionally a PostToolUse hook as a control). - From a local checkout of the default branch, boot a cloud session:
claude --cloud "inspect plugin state". - In the cloud session: check the skill surface for the plugin's skills;
ls -la ~/.claude/plugins/;cat ~/.claude/plugins/known_marketplaces.json; runclaude plugin marketplace update <name>. - Observe: the control hook fires, but no marketplace registration exists, the update command reports zero known marketplaces, and no plugin skills load.
3 Comments
This is painful
Same result here, with a few extra data points that narrow it down (Claude Code on claude.ai/code, September 2026):
extraKnownMarketplaces(a private GitHub repo in our org,autoUpdate: true) plusenabledPlugins. In the cloud sandbox,~/.claude/remote-settings.jsonis present with exactly those keys, but~/.claude/plugins/marketplaces/is empty,known_marketplaces.jsondoesn't exist andinstalled_plugins.jsonis{"version": 2, "plugins": {}}..claude/settings.jsonwith the same keys gives the same result. This matches the original report.attachablewith the caller's credential, for both read and push. With that repo attached to the session as a second source, it is cloned into the sandbox, but the marketplace is still never registered and none of the plugin's skills load.So in cloud sessions the startup step that registers declared marketplaces doesn't seem to run at all, whichever settings scope declares them. The same plugin loads fine in local sessions from the same org-managed settings.
Same wall here, with a concrete case and a workaround that shows why this needs a real fix.
Setup. All my personal skills — 108 of them, in 6 plugins — live in a private marketplace hosted in a GitHub repo (
source: "./plugins/<name>"entries), as recommended for sharing skills across machines. In a cloud session (claude.ai/code, September 2026) none of them exists: the UI says "Plugins — available only in local sessions",/<plugin>:<skill>answers "unknown command", and nothing triggers from descriptions. Repository skills (.claude/skills/of the cloned repo) do load.Workaround in use. A generated stub per skill in
.claude/skills/<skill>/SKILL.mdof the marketplace repo: original frontmatter copied byte for byte, plus a one-line body "readplugins/<p>/skills/<s>/SKILL.mdand apply it". Explicit invocation and description-based triggering both work in a cloud session, but:<plugin>:<skill>cross-reference inside the skills is wrong in the cloud;descriptionis duplicated, so a generator + drift check are needed to keep both in sync;Ask. Honour
extraKnownMarketplaces+enabledPluginsfrom a cloned repo's.claude/settings.jsonin cloud sessions (this issue), or let cloud sessions install plugins from a git-hosted marketplace the user already has access to — at least for plugins that contain only skills/commands (no MCP servers, no hooks), which need nothing beyond files.Related: #88214 (same symptom, public marketplace), #92031 (account-level plugins never sync to web), #82349 ("Unknown command" instead of an explanation).