Cowork/synced plugin packs can't be listed, inspected, or disabled; claude plugin details can't resolve them

Summary

Plugin packs delivered through the Cowork/desktop channel (claude-cowork marketplace) cannot be listed, inspected, or disabled through any interface I could find. They contribute a large share of my session's skill catalogue, and claude plugin details — which is otherwise exactly the right tool for this — reports them as not found.

I went looking because my sessions were starting at ~101k tokens of context before my first prompt, up from ~55k a few weeks earlier.

Environment

• Claude Code 2.1.258 (native install), also reproduced on 2.1.233
• Claude desktop app 1.40609.1, macOS
• Session type: desktop app (bridge session)

Reproduction

A pack that is demonstrably live in the session — its skills appear in the catalogue and are invocable — is invisible to the plugin tooling:

$ claude plugin details carta-crm
Plugin "carta-crm" not found. Run `claude plugin list` to see installed plugins,
or pass --plugin-dir <path> to load one from disk.

$ claude plugin details carta-crm@synced
Plugin "carta-crm@synced" not found.

claude plugin list --json returns 42 entries, all from two marketplaces:

total entries : 42
@synced       : 0
cowork        : 0
by marketplace: {claude-plugins-official: 41, convex: 1}

Meanwhile the payload is on disk:

$ find ~/.codex/plugins/cache/claude-cowork -maxdepth 1 -mindepth 1 -type d | wc -l
55
$ find ~/.codex/plugins/cache/claude-cowork -name SKILL.md | wc -l
461

Not all 55 are active — reading my session's skill catalogue by hand, roughly 33 of them are, contributing on the order of 250 skill entries. I can't give an exact figure, which is the point of the issue.

(Worth noting on its own: these are cached under ~/.codex/, not ~/.claude/.)

What I ruled out

Searching for an enablement flag for these packs, I checked and found nothing in:

• ~/.claude/settings.json → enabledPlugins
• ~/.claude/plugins/installed_plugins.json
• ~/.claude/plugins/known_marketplaces.json
• ~/.codex/config.toml → [plugins.*] (12 entries, none from claude-cowork)
• ~/Library/Application Support/Claude/Claude Extensions Settings/ (empty)
• cowork-clientdata-cache.json, cowork-gb-cache.json

Nothing on disk distinguishes the ~33 live packs from the ~22 cached-but-inactive ones, which suggests the selection happens server-side. I could not find a client-side surface that exposes it.

I also tried the name@synced form added in 2.1.239, since the changelog entry looked like it might apply. It does not — that entry scopes the feature to cloud sessions, and this is a local desktop session.

Impact

Measured with the CLI's own accounting (claude plugin details, summed across my enabled set), my 29 locally-installed plugins cost ~14.6k always-on tokens — ~29.2k before I disabled 13 of them. Those I can see and manage.

The Cowork packs I cannot measure at all, because the tool that measures plugins cannot resolve them. That's the gap: the manageable half is instrumented, the unmanageable half is invisible.

Requests

1. Make Cowork/synced packs visible to claude plugin list and claude plugin details, even if read-only, so their cost is at least attributable.
2. Provide a way to disable them. A per-pack toggle in whichever surface owns them, or CLI parity with claude plugin disable.
3. An aggregate view. claude plugin details is genuinely good — per-component always-on vs on-invoke costs, and it correctly excludes harness-only hooks. But answering "what is my startup context made of" currently means running it once per plugin and summing by hand. A --all flag, or a /context that attributes the startup baseline by source (tools, MCP instructions, skill catalogue, agent roster, memory), would turn this from an afternoon into one command.

Happy to provide more detail from my install if useful.