[BUG] Repo-committed extraKnownMarketplaces + enabledPlugins never processed in claude.ai/code cloud sandboxes (hooks from the same settings.json work)

Status Open
Reported on v2.1.211
Maintainer reply None cached
Activity 3 comments · opened Jul 16, 2026

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 hooks key from this file IS honored: the PostToolUse hook fires repeatedly, $CLAUDE_PROJECT_DIR expands, hook output is injected. So the committed file is read and trusted.
  • The extraKnownMarketplaces key is never processed: ~/.claude/plugins/known_marketplaces.json does not exist at any point in the session, before or after any command. ~/.claude/plugins/ contains only an empty installed_plugins.json ({"version": 2, "plugins": {}}) whose mtime predates the session (baked into the sandbox image). No marketplaces/ directory, no cache/ directory.
  • Consequently enabledPlugins cannot resolve: none of the plugin's skills appear in the session's skill surface, and /myplugin:... commands are unknown.
  • claude plugin marketplace update myteam inside the sandbox fails with Marketplace '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

  1. In a private repo, commit the .claude/settings.json above on the default branch (marketplace source = the repo itself; any plugin with at least one skill; optionally a PostToolUse hook as a control).
  2. From a local checkout of the default branch, boot a cloud session: claude --cloud "inspect plugin state".
  3. In the cloud session: check the skill surface for the plugin's skills; ls -la ~/.claude/plugins/; cat ~/.claude/plugins/known_marketplaces.json; run claude plugin marketplace update <name>.
  4. Observe: the control hook fires, but no marketplace registration exists, the update command reports zero known marketplaces, and no plugin skills load.

View original on GitHub ↗

3 Comments

fostimus · 2 months ago

This is painful

mmsmits · 20 days ago

Same result here, with a few extra data points that narrow it down (Claude Code on claude.ai/code, September 2026):

  • Org-managed settings are affected too, not only repo settings. Our org-managed settings declare extraKnownMarketplaces (a private GitHub repo in our org, autoUpdate: true) plus enabledPlugins. In the cloud sandbox, ~/.claude/remote-settings.json is present with exactly those keys, but ~/.claude/plugins/marketplaces/ is empty, known_marketplaces.json doesn't exist and installed_plugins.json is {"version": 2, "plugins": {}}.
  • A repo-level .claude/settings.json with the same keys gives the same result. This matches the original report.
  • It isn't an access problem. A sandbox check reported the private marketplace repo as attachable with 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.

RubenARNAUD · 17 days ago

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.md of the marketplace repo: original frontmatter copied byte for byte, plus a one-line body "read plugins/<p>/skills/<s>/SKILL.md and apply it". Explicit invocation and description-based triggering both work in a cloud session, but:

  • it only works when the marketplace repo is one of the session's repos;
  • skills load under their bare name, so every <plugin>:<skill> cross-reference inside the skills is wrong in the cloud;
  • "Base directory for this skill" points at the stub, not at the plugin folder where the scripts live;
  • the description is duplicated, so a generator + drift check are needed to keep both in sync;
  • in a local session opened on that repo, every skill appears twice (stub + plugin).

Ask. Honour extraKnownMarketplaces + enabledPlugins from a cloned repo's .claude/settings.json in 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).