Agent-type roster is not user-controllable: bundled plugins + cross-project memory occupy 111.5k tokens in every session, and three documented workarounds have no effect

Status Open
Reported on v2.1.199
Maintainer reply None cached
Activity 0 comments · opened Aug 3, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Environment

  • Claude Code 2.1.199, desktop app, Windows 11 (win32)
  • Single ~/.claude config dir
  • At time of final measurement: zero plugins installed, zero enabled, no marketplace registered

Summary

The per-session list of subagent_type values (given to the model as "Available agent types for the Agent tool") contains 669 entries / 236,120 characters = 111.5k tokens as measured by /context. Only 18 of those are agents the user actually authored.

The rest comes from two sources the user cannot control:

  1. ~170 bundled plugin/agent entries (math-olympiad, claude-security, code-simplifier, receipts, plugin-validator, several *-lsp, …) — present with zero plugins installed and no marketplace registered.
  2. 413 memory-file entries from 7 different projects — a session working in PROJECT-A carries 195 entries belonging to the unrelated PROJECT-B.

I tried three separate mechanisms to reduce this. All three had no effect on the roster. Details below, each with verified pre/post conditions.

Impact (measured, not estimated)

From /context (real tokenizer): roster 111.5k tokens, vs memory files 32.4k, system tools 16.0k, skills 10.0k, system prompt 4.9k. With 182.8k of a 1M window in use, the roster is ~61% of everything the session carries.

This is not a per-session cost — it is a per-turn cost. Parsing usage from every local transcript over 14 days (363 sessions):

| | tokens | share |
|---|---:|---:|
| cache_read | 8,253,138,020 | 91.2% |
| cache_write | 789,474,500 | 8.7% |
| input | 6,286,551 | 0.1% |

Cost is context size × turns, and the roster sits in the system prompt of every turn. Median session length is 94 turns (p90 = 226). So ~111.5k of entries the user cannot remove — of which only 18 entries are theirs — is re-charged on the order of a hundred times per session, hundreds of sessions per fortnight.

Workaround 1 — remove the marketplace: NO EFFECT

Hypothesis: the roster walks the local marketplace catalog clone (the ~40 example plugins under ~/.claude/plugins/marketplaces/<name>/plugins/). The description shown in the roster for math-olympiad is near-verbatim the one in that folder's plugin.json, which made this look certain.

  • Ran claude plugin marketplace remove claude-plugins-official
  • Verified: known_marketplaces.json = {} · installed_plugins.json = {} · enabledPlugins = {} · the entire ~/.claude/plugins/marketplaces/ directory gone from disk
  • Restarted the app (process start time verified to be after the removal)
  • Fresh session

Result: roster unchanged — 111.5k / 663 entries, math-olympiad, claude-security, code-simplifier, receipts all still listed.

Note the UI and CLI both report these plugins as absent: Settings → Plugins is empty, and claude plugin details math-olympiad returns "not found. Run claude plugin list to see installed plugins". Yet they occupy the roster.

Workaround 2 — environment switches: NO EFFECT on the roster

Set via env in settings.json, verified to actually reach the process environment (positive control: the variables read back as 1; negative control: an invented variable name reads back empty):

  • CLAUDE_CODE_DISABLE_BUNDLED_SKILLS=1
  • CLAUDE_CODE_DISABLE_POLICY_SKILLS=1
  • CLAUDE_CODE_DISABLE_CLAUDE_API_SKILL=1

App restarted afterwards (process start verified after the edit); measured in a session created after the restart, by reading the agent_listing_delta and skill_listing objects directly from the session transcript.

| listing | before | after |
|---|---:|---:|
| agent_listing_delta (the roster) | 669 | 669 — unchanged |
| skill_listing | 76 | 53 |

So the switches do work — but only on the skill listing, not on the agent roster. dataviz, anthropic-skills:*, claude-api, update-config left the skill listing; math-olympiad and the other bundled plugin entries stayed in the roster.

This suggests the agent roster and the skill listing are built by separate code paths, and only the latter honours the documented opt-outs.

Workaround 3 — skillOverrides: NO EFFECT

settings.local.json sets 31 skills to user-invocable-only. 27 of those 31 are still in the roster.

Separately: of 83 local skills on disk, 62 appear in the roster and 21 do not — and I could not find what distinguishes them. Not any frontmatter key, not creation or modification date. The only clean signal is that all 49 skills whose description uses a YAML block scalar (>-) are in the roster, while single-line descriptions are split 13 in / 21 out. I tested converting one skill's description from block to single-line: it stayed in the roster. So even that correlation is not the mechanism.

Questions

  1. With zero plugins installed, zero enabled, no marketplace registered, and CLAUDE_CODE_DISABLE_BUNDLED_SKILLS=1 set — is there any supported way to keep bundled plugin entries out of the agent roster?
  2. Is the roster intended to ignore install/enable state entirely? If so this should be documented, because the UI and CLI both tell the user those plugins are not present.
  3. Is including memory files from all projects intended? The memory documentation describes per-project scope and states that topic files are "not loaded at startup".
  4. Why do the DISABLE_* switches affect skill_listing but not agent_listing_delta? Is that intentional?
  5. Is any size cap planned? The roster scales without bound with the number of memory notes a user accumulates across every project they have ever opened — in my case 413 entries and growing daily.

Why this matters

For a single-user setup, this is the difference between a workload that fits inside a subscription's weekly limit and one that does not. 68% of my roster (memory 43% + bundled plugins 25%) is content I did not create and cannot remove, re-read on every turn of every session.

What Should Happen?

For a single-user setup, this is the difference between a workload that fits inside a subscription's weekly limit and one that does not. 68% of my roster (memory 43% + bundled plugins 25%) is content I did not create and cannot remove, re-read on every turn of every session.

Error Messages/Logs

Steps to Reproduce

run Claude

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.24012.9

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗