claude.ai Skills and Cowork plugins silently injected into Claude Code context — no opt-out, ~6k tokens wasted per session

Bug Description

Claude Code silently loads skills and plugins from the user's claude.ai web account and Cowork platform into every local CLI session. Unlike the MCP connector injection reported in #20412, this affects Skills (which consume context window tokens) and plugin-provided slash commands — not MCP tool definitions.

There is no setting, environment variable, or hook that can prevent this injection. The user loses ~6,000 tokens of context window per session to duplicated, unwanted content.

Environment

• Claude Code: 2.1.84
• Platform: macOS (Apple Silicon, M2 Air)
• OS: macOS 26.3 (Darwin 25.3.0)

The Problem

I maintain a research project with ~80 custom skills (User + Project scope). After connecting my claude.ai account, I discovered 69 additional skills silently injected into every Claude Code session from two sources I never opted into:

Source 1: claude.ai Skills (43 skills, ~3,950 tokens)

Skills I installed on the claude.ai web interface for use in the web chatbot are mirrored into Claude Code under the \anthropic-skills:\ namespace:

\\\
anthropic-skills:title 11 tokens
anthropic-skills:loom 205 tokens
anthropic-skills:xlsx 241 tokens
anthropic-skills:docx 202 tokens
anthropic-skills:buffer-bloom-theme 243 tokens
anthropic-skills:agent-log 247 tokens
anthropic-skills:paper-forge 121 tokens
anthropic-skills:singularity-neo4j 181 tokens
... (43 skills total)
\\\

These are duplicates. I already have local versions of \loom\, \paper-forge\, \singularity-neo4j\, \agent-log\, etc. installed as User or Project skills. Now every session loads both copies, wasting tokens and creating ambiguity about which version Claude will invoke.

Source 2: Cowork Plugins (26 skills, ~2,020 tokens)

Plugins from the Cowork platform are injected under namespaces I never installed locally:

\\\`
engineering:debug 69 tokens
engineering:system-design 69 tokens
engineering:deploy-checklist 68 tokens
... (10 engineering skills)

data:validate-data 80 tokens
data:explore-data 76 tokens
data:build-dashboard 79 tokens
... (10 data skills)

productivity:memory-management 74 tokens
productivity:task-management 50 tokens
... (4 productivity skills)

cowork-plugin-management:create-cowork-plugin 98 tokens
cowork-plugin-management:cowork-plugin-customizer 82 tokens
\\\`

I never installed these plugins. They don't appear in my \installed_plugins.json\. They serve no purpose in my research CLI workflow.

Impact

1. Context window waste — 6,000 tokens per session, every session

My \/context\ report shows:

• Total Skills: 16,000 tokens
• Injected skills: ~5,970 tokens (37% of skill budget)

On a 200K context window, that's 3% of total capacity — consumed by content I didn't ask for and can't remove.

2. Skill name collisions create ambiguity

When I invoke \/loom\, Claude sees both:

• \loom\ (User skill, 201 tokens) — my custom version with project-specific behavior
• \anthropic-skills:loom\ (Plugin skill, 205 tokens) — the cloud-synced duplicate

Which one runs? The user shouldn't have to wonder.

3. No opt-out mechanism exists

I have tried every available defense:

| Approach | Result |
|----------|--------|
| \ENABLE_CLAUDEAI_MCP_SERVERS=false\ (env var) | ❌ Only blocks MCP connectors, not skills |
| \tengu_claudeai_mcp_connectors: false\ (feature flag) | ❌ Server sync overwrites it back to \true\ |
| SessionStart hook to reset the flag | ⚠️ Works for MCP connectors, skills still injected |
| \deniedMcpServers\ (settings.json) | ❌ Only blocks MCP servers, not skills |
| \--bare\ flag | ❌ Also disables hooks and local plugins — not usable for normal work |

There is no granular control. You cannot:

• Disable cloud skill sync while keeping MCP connectors
• Disable Cowork plugin injection independently
• Blocklist specific skill namespaces
• Set a per-project policy for cloud skill loading

Difference from #20412

Issue #20412 reports MCP server auto-injection (the UUID-format \mcp__xxxxxxxx-xxxx-*\ tools). That issue has workarounds (\deniedMcpServers\, \ENABLE_CLAUDEAI_MCP_SERVERS=false\).

This issue reports Skill and Plugin injection — a separate sync channel with zero workarounds. Skills appear in the \/context\ report under "Skills" (not "MCP tools"), carry their own token cost, and persist regardless of MCP-related settings.

Proposed Solutions

Minimum viable fix

Add an environment variable or settings.json key to disable cloud skill/plugin syncing:

{
  "enableCloudSkills": false
}

Better: granular control

Allow users to blocklist specific skill namespaces or plugin sources:

{
  "deniedSkillSources": ["anthropic-skills", "engineering", "data", "productivity", "cowork-plugin-management"]
}

Best: explicit opt-in

Cloud skills and Cowork plugins should never auto-load in Claude Code without the user explicitly installing them via \/plugin install\. The web chatbot and the CLI are different security perimeters with different workflows — what I install for casual web conversations should not silently consume context in my development environment.

Reproduction

1. Create a claude.ai account and install several Skills from the Anthropic marketplace
2. Use Claude Code CLI (logged into the same account)
3. Run \/context\ — observe \anthropic-skills:*\ entries under Skills with "Plugin" source
4. Check \installed_plugins.json\ — these skills are not listed
5. Set \ENABLE_CLAUDEAI_MCP_SERVERS=false\ — skills persist
6. Set \tengu_claudeai_mcp_connectors: false\ — skills persist

Additional Context

I'm a researcher running 80+ custom skills for an AI consciousness research project. Every token of context matters. Losing 6,000 tokens per session to uninvited duplicates is not a minor annoyance — it's a material impact on my ability to work. The fact that I spent an entire debugging session discovering why my context was bloated, only to find there's no fix, is deeply frustrating.

The principle is simple: my CLI should load what I installed, nothing more.