Unused MCP Plugins Are Quietly Eating Your Context: A Weekly Auto-Disable Pipeline

This is a continuation of my "Claude Code environment" series. After the previous post on automating git-config backups, this time I'm tackling a problem that sneaks up on you: MCP plugins you enabled once and forgot about keep chipping away at your context, and I'll walk through the three-stage pipeline that auto-disables them on a weekly schedule.

When you enable a plugin, its tool schema is injected at startup even if it's never called once. As these "just leave it on" plugins pile up, the token budget Claude actually has to work with quietly shrinks. In this article I connect detection, auto-disable, and cache archiving into a single flow with real code.

The problem: plugin management that adds but never subtracts

The motivation to install a new plugin is clear. "I want to use this tool" is an active urge. There's no equivalent motivation to remove one. You never get a moment where you notice "hmm, I haven't used that plugin lately."

At the start of every session, Claude Code injects the tool schemas of every plugin marked true under enabledPlugins in settings.json into the context. The more plugins that are "enabled but haven't been invoked once in 30 days," the more the top of your context gets filled with zero-contribution schema on every single run.

After a few months of trying things out and leaving them enabled, the count of Dormant plugins (enabled but unused) can climb past 30.

Architecture: a three-stage pipeline

plugin-usage.sh       → visualize dormant plugins (manual run / weekly report)
plugin-auto-disable.sh → auto-disable anything unused for 30 days, weekly
cleanup-plugin-cache.sh → archive disabled caches into .disabled-cache/

The tail of plugin-auto-disable.sh apply chain-calls cleanup-plugin-cache.sh apply, so there's a single entry point for launchd to start.

Step 1 — Visualize dormant plugins with plugin-usage.sh

~/.claude/scripts/plugin-usage.sh aggregates, from the session JSONL of the past N days (14 by default), only the plugins that were actually invoked as a tool_use.

# plugin-usage.sh excerpt
LOG_DIR="$HOME/.claude/projects/-Users-matsubara"
DAYS="${1:-14}"

find "$LOG_DIR" -maxdepth 1 -name "*.jsonl" -mtime -"$DAYS" -print0 2>/dev/null | xargs -0 cat 2>/dev/null \
  | jq -R -r 'fromjson? | select(.type=="assistant") | .message.content[]? | select(.type=="tool_use")
      | if .name=="Skill" then ((.input.skill // "") | select(contains(":")) | split(":")[0])
        else (.name | select(startswith("mcp__plugin_")) | sub("^mcp__plugin_";"") | split("_")[0]) end' 2>/dev/null \
  | sort | uniq -c | sort -rn > "$TMP"

It reports the gap between the number of enabled plugins and the number of distinct invocations as Dormant.

TOTAL_ENABLED=$(jq -r '[.enabledPlugins // {} | to_entries[] | select(.value)] | length' "$SETTINGS")
# Dormant = TOTAL_ENABLED - USED_COUNT

Why aggregate with jq instead of grep

The old implementation used grep for substring matching. It miscounted the "full list of deferred tools" lines in the JSONL (a very long list of available tool names) as "invocations," which made things like terraform show up near the top even though they were never called, and could even make the Dormant count go negative. Passing everything through select(.type=="tool_use") fixes this so that only calls that were actually invoked are counted.

Sample output:

## Summary
- Enabled plugins: **62**
- Distinct plugins referenced in logs: **29**
- Dormant (enabled but never invoked): **33**

## Dormant Plugins (enabled, no recent invocation)
_Candidates for disabling to reduce context tax_
...

## Recommendation
- 33 plugins enabled but unused in last 14 days
- Heavy dormant load — disabling these could free significant context budget
- To disable a plugin: edit `enabledPlugins` in ~/.claude/settings.json

Once Dormant exceeds 30, it prints "Heavy dormant load". This threshold is hardcoded inside the script.

Step 2 — plugin-auto-disable.sh disables automatically, weekly

~/.claude/scripts/plugin-auto-disable.sh is the core. It defaults to dry (no changes); pass apply and it actually disables plugins.

# plugin-auto-disable.sh excerpt
MODE="${1:-dry}"
DAYS="${DAYS:-30}"             # observation window (default 30 days)
MIN_CACHE_MB="${MIN_CACHE_MB:-5}"    # skip caches smaller than 5MB
WEEKLY_MAX="${WEEKLY_MAX:-5}"        # at most 5 per run

Operational flow:

1. Index the MCP calls and Skill calls from the past 30 days of JSONL
2. Get the list of plugins marked true in enabledPlugins via python3
3. Exclude anything in the PROTECTED list
4. Sort candidates by cache size descending, and narrow to those at least MIN_CACHE_MB, up to WEEKLY_MAX entries
5. In apply mode, run plugin-disable.sh apply → cleanup-plugin-cache.sh apply in sequence

# sort candidates by size and pick up to WEEKLY_MAX
SIZED=()
for p in "${CANDIDATES[@]}"; do
  size=$(du -sm "$HOME/.claude/plugins/cache/claude-plugins-official/$p" 2>/dev/null | awk '{print $1}')
  size="${size:-0}"
  [ "$size" -lt "$MIN_CACHE_MB" ] && continue
  SIZED+=("${size}\t${p}")
done

SELECTED=()
while IFS=$'\t' read -r sz p; do
  SELECTED+=("$p")
  [ "${#SELECTED[@]}" -ge "$WEEKLY_MAX" ] && break
done < <(printf '%b\n' "${SIZED[@]}" | sort -rn)

Prioritizing by cache size descending is so the ones that free up the most context get processed first.

Designing the PROTECTED list

The biggest risk of auto-disabling is false positives. The PROTECTED array exists to protect plugins that are "barely used but painful to lose."

PROTECTED=(
  remember plugin-dev hookify skill-creator session-report
  security-guidance superpowers context7 explanatory-output-style
  learning-output-style code-review feature-dev claude-md-management
  # LSPs: Claude Code may call these transparently. They don't appear as tool_use
  typescript-lsp pyright-lsp php-lsp ruby-lsp rust-analyzer-lsp swift-lsp
  # Process tools: may be called ad-hoc
  code-simplifier code-modernization ralph-loop agent-sdk-dev mcp-server-dev
  playground commit-commands pr-review-toolkit
  # Known false positive (trouble in a past session)
  azure-cosmos-db-assistant
)

Why each category is protected:

Category	Examples	Reason to protect
Infrastructure	hookify superpowers remember	Core of startup hooks and skill invocation. Don't appear as tool_use in the JSONL
LSP	typescript-lsp, etc.	Claude Code itself calls them transparently, internally. Not recorded in logs
Dev support	code-review feature-dev	Used ad-hoc. Needed even after long stretches of no calls
Known false positive	azure-cosmos-db-assistant	Caused trouble when auto-disabled in the past

If you don't put the LSPs in PROTECTED, you jam up immediately

typescript-lsp and friends are used internally by Claude Code itself. Since the user never explicitly invokes them as a Skill tool or MCP tool, they don't appear in the tool_use logs. If they aren't in PROTECTED, they get auto-disabled while you're using them normally.

Step 3 — Archive caches with cleanup-plugin-cache.sh

Even after you disable a plugin, its cache remains under ~/.claude/plugins/cache/. cleanup-plugin-cache.sh moves those into ~/.claude/plugins/.disabled-cache/.

# cleanup-plugin-cache.sh excerpt
CACHE_DIR="$HOME/.claude/plugins/cache/claude-plugins-official"
ARCHIVE_DIR="$HOME/.claude/plugins/.disabled-cache"
PURGE_DAYS="${PURGE_DAYS:-30}"

for dir in "$CACHE_DIR"/*/; do
  name=$(basename "$dir")
  if ! echo "$ENABLED" | grep -qx "$name"; then
    if [ "$MODE" = "apply" ]; then
      mv "$dir" "$ARCHIVE_DIR/" && echo "  archived: $name"
    fi
  fi
done

It never actually deletes. It only moves things aside with mv, so restoring is reversible with a single mv.

On top of that, the purge submode can physically delete only those items left in .disabled-cache/ for at least PURGE_DAYS (default 30 days).

# physically delete 30 days after archiving
~/.claude/scripts/cleanup-plugin-cache.sh purge

Automate it with launchd at 06:45 on Sundays

I set the weekly schedule in ~/Library/LaunchAgents/com.shun.plugin-auto-disable.plist.

<key>StartCalendarInterval</key>
<dict>
  <key>Hour</key>
  <integer>6</integer>
  <key>Minute</key>
  <integer>45</integer>
  <key>Weekday</key>
  <integer>0</integer>   <!-- 0 = Sunday -->
</dict>

Every Sunday at 06:45, plugin-auto-disable.sh apply runs, and its logs are appended to ~/.claude/logs/plugin-auto-disable.log.

Registering and checking:

# register
launchctl load ~/Library/LaunchAgents/com.shun.plugin-auto-disable.plist

# check it's running
launchctl list | grep plugin-auto-disable

# manual test (no changes)
~/.claude/scripts/plugin-auto-disable.sh dry

# manual run
~/.claude/scripts/plugin-auto-disable.sh apply

Pitfalls I hit

• grep's substring matching picked up the deferred-tools listing lines as "invocations" → until I made jq explicitly filter type=="tool_use", the Dormant count went negative. Things like terraform showed up near the top as ghosts.
• Forgetting to put the LSPs in PROTECTED, so they get disabled → after typescript-lsp was removed, type checking stopped working. Added it to PROTECTED and restored it.
• Without setting MIN_CACHE_MB, plugins with tiny caches become targets → anything under 5MB has small impact and only carries risk. Filtered at a 5MB default.
• Setting WEEKLY_MAX too high drags in plugins you need → capped at 5 per week. There's no need to rush and do it all at once.
• launchd skips jobs while the Mac is asleep → Sunday morning at 06:45 is a time the machine is often awake. Even if it's skipped, it just carries over to the next week, with no real harm.
• If plugin-disable.sh doesn't exist, apply is a no-op → plugin-auto-disable.sh is a wrapper that calls this script internally. It won't work unless you have the full set of scripts in place.

Summary

• plugin-usage.sh aggregates the real tool_use events from session JSONL and visualizes dormant plugins
• The old grep implementation miscounts the deferred-tools listing lines. The right fix is to make jq explicitly filter type=="tool_use"
• plugin-auto-disable.sh auto-disables based on 30-day inactivity, a 5MB-plus cache, and a cap of 5 per week
• Always put LSPs, infrastructure plugins, and known false positives in the PROTECTED list. If you don't, plugins you need get removed
• cleanup-plugin-cache.sh archives caches into .disabled-cache/, with physical deletion via purge after 30 days
• launchd with Weekday=0 / Hour=6 / Minute=45 runs it unattended every Sunday at 06:45

Next time, to verify the context headroom this buys back, I'll write about the real-time context-usage meter in the statusline that I built.

---

Written by **Lily* — I ship iOS apps and automate my content stack with Claude Code.
Follow along: Portfolio · X · GitHub*

Comments

[Skillselion]

One failure mode worth guarding before the apply step: zero tool_use in 30 days is not always "dormant by choice." A plugin can sit unused because another plugin with an overlapping tool description shadows it, or because its one job is quarterly (release tooling, cert rotation, incident helpers). The JSONL tells you it never fired, not why. Two cheap additions would cover most of it: keep a small allowlist of "rare but load-bearing" plugins the auto-disable never touches, and before disabling, grep CLAUDE.md and project docs for the plugin's tool names, because if the instructions still reference it, disabling it creates the stale-docs problem in reverse (docs promise a tool the runtime no longer has). Worth noting the raw context cost is smaller on recent versions where deferred tool loading only pays for tool names up front, but the shadowing and quarterly-tool failure modes hold either way. The archive-instead-of-delete design you already have is the right call; the missing piece is distinguishing "unused" from "unused this window."

[Alex Shev]

The weekly auto-disable idea is strong because context waste usually hides in “just in case” tools. I would want the pipeline to separate never-used from rarely-used-but-critical, though. A plugin that fires once a month for a sensitive workflow should probably be parked differently than one that never had a real trigger.

[Mads Hansen]

This is a very real problem. MCP tools have a context cost even when they never execute, so “enabled forever” is not a neutral default.

The protected list and dry-run mode feel essential. I would also track the actual schema-token cost per plugin, not just cache size, because the expensive part for the model is the exposed tool surface. A small plugin with a huge tool schema can be worse than a large cache with one narrow tool.

The rare-but-critical tools are the dangerous edge case. For those, I would rather mark them protected with an owner/reason than let usage frequency alone decide.