Cloud sessions never install plugins declared in .claude/settings.json, and /plugin is unavailable to fix it

Summary

In a cloud session (Claude Code on the web), plugins declared in a repo's
.claude/settings.json are never installed. installed_plugins.json stays empty, none of the
plugins' skills or agents load, and there is no way to remediate from inside the session.

This is specifically about the cloud surface, where the documented contract is different from
local. Cloud environments → What carries over from your setup
states:

Plugins declared in .claude/settings.json — Yes — Installed at session start from the marketplace you declared. Requires network access to reach the marketplace source

That auto-install does not happen. And unlike the local case, there is no fallback: /plugin
is documented as unavailable in cloud sessions,
so /plugin install cannot be used to fix it.

Environment

• Claude Code on the web, Anthropic-hosted cloud environment, Ubuntu 24.04 x86_64, running as root
• Network access: Trusted (the marketplace fetch itself succeeds — see below)
• Five plugins declared in the repo's .claude/settings.json, from the public

claude-plugins-official marketplace (anthropics/claude-plugins-official)

Evidence

Observed 2026-08-20 in a cached (non-first) cloud session.

The marketplace syncs fine, so this is not network. known_marketplaces.json was written
during this boot:

{ "claude-plugins-official": {
    "source": { "source": "github", "repo": "anthropics/claude-plugins-official" },
    "installLocation": "/root/.claude/plugins/marketplaces/claude-plugins-official",
    "lastUpdated": "2026-08-20T03:29:09.879Z" } }

and its catalog on disk contains every declared plugin:

$ ls ~/.claude/plugins/marketplaces/claude-plugins-official/plugins/ | grep -E 'ruby-lsp|swift-lsp'
ruby-lsp
swift-lsp

But nothing is installed:

$ cat ~/.claude/plugins/installed_plugins.json
{ "version": 2, "plugins": {} }

$ ls ~/.claude/plugins/synced/
(empty)

And the cache holds only metadata, no plugin content — no manifest, no skills, no agents:

$ find ~/.claude/plugins/cache -maxdepth 6
.../cache/claude-plugins-official/ruby-lsp/1.0.0/README.md
.../cache/claude-plugins-official/ruby-lsp/1.0.0/LICENSE
.../cache/claude-plugins-official/swift-lsp/1.0.0/README.md
.../cache/claude-plugins-official/swift-lsp/1.0.0/LICENSE

That looks like the fetch starts and stops after the metadata files.

Confirmed by what the session can actually see. pr-review-toolkit ships six agents:

$ ls ~/.claude/plugins/marketplaces/claude-plugins-official/plugins/pr-review-toolkit/agents
code-reviewer.md  code-simplifier.md  comment-analyzer.md
pr-test-analyzer.md  silent-failure-hunter.md  type-design-analyzer.md

None of the six appear in the session's available agent types.

Two secondary observations

1. Plugin state is rebuilt from empty on every boot. The whole ~/.claude/plugins/ tree is
stamped with the current boot time in every session, while other snapshot-restored files carry
their original mtimes. So even a successful install could not persist across sessions in the
same environment — which matters because cloud environments boot from a cached filesystem
snapshot rather than re-running setup.

2. Only one marketplace registers. extraKnownMarketplaces declared both
claude-plugins-official and claude-code-plugins (source anthropics/claude-code). Only the
former ever appears in known_marketplaces.json in a cloud session. Both register normally on
macOS, and claude-code-plugins also resolves fine when passed to claude-code-action in CI —
so this appears specific to the cloud session's marketplace registration.

Expected

Either the documented auto-install works, or a cloud session reports at startup that declared
plugins could not be installed. Today it is silent: the plugins simply are not there, and the
absence looks identical to not having declared them.

Impact

Any team sharing plugins through committed .claude/settings.json — the documented
team-sharing pattern — gets those plugins on developer machines and in CI, but not in cloud
sessions. Because /plugin is unavailable there, nothing in the repo or in the session can
work around it.

Related

• #83422 — same "enabled in settings but never installed, silently" shape, but reported for

local sessions where /plugin install is an available remedy. In cloud it is not, and the
documentation promises auto-install rather than requesting it.

• #76759 — the inverse population failure (installed_plugins.json written without the cache

populated); here the cache is partially populated and the record is missing.