[BUG] `extraKnownMarketplaces` in `managed-settings.json` is ignored

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/13097
2. https://github.com/anthropics/claude-code/issues/13096
3. https://github.com/anthropics/claude-code/issues/16383

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

Can confirm this is an issue for us as well.

Doesn't work for us either

@ndhansen and @yuyuma , could you share

"source": {
        "source": "git",
        "url": "redacted_but_keep_all_format"
      }

@whyuan-cc Sure!

{
  "extraKnownMarketplaces": {
    "company-tools": {
      "source": {
        "source": "git",
        "url": "https://git.internal/Company/claude-plugins.git"
      }
    }
  }
}

Adding that URL works if I run claude plugin marketplace add ..., and it mirrors what the docs claim I should be doing.

Also seeing this issue in our org

Is there a plan to fix this?

Also hitting this in our org. We maintain a custom marketplace with internal tooling plugins; requiring each developer to run /plugin marketplace add manually blocks team rollout.

Our setup: we commit extraKnownMarketplaces to .claude/settings.json to declare the marketplace at the project level and set enabledPlugins to activate plugins for the whole team. Because extraKnownMarketplaces is silently ignored, the plugin never installs and enabledPlugins does nothing.

The fix is either:

• auto-install plugins listed in enabledPlugins whose marketplace appears in extraKnownMarketplaces, or
• prompt the user to install them on first run.

Without this, project-level plugin distribution is broken for any company trying to standardize tooling across a team.

Confirming this also affects Claude Code on the web (remote-execution container), so it's not CLI/desktop-specific — same area:core code path, and the same OS as the original repro (Linux). This looks like the web analog of #70318 (Windows Desktop), which was closed as a duplicate.

Environment

• Surface: Claude Code on the web / remote-execution environment
• OS: Linux (managed container)
• Managed settings version reported in remote-settings.json: v1.33.7

What happens

Org-managed plugins are declared in server-managed remote settings and land correctly in ~/.claude/remote-settings.json:

{
  "enabledPlugins": {
    "pluginA@marketplaceA": true,
    "pluginB@marketplaceB": true
  },
  "extraKnownMarketplaces": {
    "marketplaceA": { "autoUpdate": true, "source": { "repo": "owner/marketplaceA", "source": "github" } },
    "marketplaceB": { "autoUpdate": true, "source": { "repo": "owner/marketplaceB", "source": "github" } }
  },
  "forceRemoteSettingsRefresh": true
}

…but the marketplace registration / plugin init step never runs, so the plugins never load:

• ~/.claude/plugins/marketplaces/ is empty (nothing cloned)
• ~/.claude/plugins/installed_plugins.json → { "version": 2, "plugins": {} }
• ~/.claude/plugins/config.json → { "version": 2, "plugins": {} }
• None of the enabledPlugins surface as skills/commands in the session

So it's the same underlying defect as this issue (extraKnownMarketplaces from managed/remote settings ignored), but reproduced via enabledPlugins + GitHub-sourced marketplaces on the web surface.

Why the web case is worse than CLI/desktop

There is no workaround on web. The desktop fix in #70318 was to run /plugin marketplace add once in the CLI — but a web session is non-interactive: there's no /plugin TUI to inspect the blank marketplace list, and no CLI on the same machine to register the marketplace manually. The result is that org-managed plugins are silently completely unavailable, with no error surfaced to the user.

Expected

On session start, Claude Code on the web should process extraKnownMarketplaces from remote settings — clone/register the marketplaces and install the plugins listed in enabledPlugins — the same init the CLI is supposed to perform, and surface an error if registration fails rather than silently no-op.

Related: #70318 (Windows Desktop, closed as duplicate).