Understanding enabledPlugins in Claude Code

enabledPlugins is the block in your Claude Code settings.json that records which installed plugins are switched on. You rarely write it by hand because the /plugin command edits it for you, but understanding what it represents explains why a plugin sometimes stays active even after you think you disabled it.

What the setting looks like

enabledPlugins is a JSON object. Each key is a plugin identifier and each value is a boolean:

"enabledPlugins": {
  "code-review@claude-plugins-official": false,
  "chrome-devtools-mcp@claude-plugins-official": true
}

The key is always plugin-name@marketplace-name. The marketplace half is not decoration: the same plugin name can exist in two marketplaces, and the identifier is what keeps them apart. This is why the /plugin menu shows you both parts when you install.

Three states, not two

A boolean value suggests two states, but a plugin actually has three, because it can also be unlisted, i.e., absent from the settings.json:

• true — the plugin is active and loaded into your session.
• false — the plugin is installed but disabled. It stays on disk; it just does not load.
• absent — the plugin is not mentioned at all. Claude Code falls back to the plugin’s own defaultEnabled field in its plugin.json, which itself defaults to true.

The third state matters. “Not in my settings.json” does not mean “off.” A freshly installed plugin that ships with defaultEnabled: true is active before your settings file says a single word about it. enabledPlugins is an override layer on top of each plugin’s own default, not the sole source of truth.

Why scope decides who wins

Claude Code reads settings from four places, and they are layered from strongest to weakest:

1. Managed (managed-settings.json) is set by your organization; cannot be overridden.
2. Local (.claude/settings.local.json) is your personal, gitignored overrides for one machine.
3. Project (.claude/settings.json) is shared with the team, committed to the repository.
4. User (~/.claude/settings.json) is your defaults across every project.

Higher layers win. This produces the behavior that surprises people most: a plugin a project enables cannot be turned off by your user settings. If .claude/settings.json in the repo sets a plugin to true, writing false in your ~/.claude/settings.json changes nothing, because project beats user. The lever that does work is .claude/settings.local.json, which sits above project scope and stays out of git.

Read the layering the other way and the design makes sense: a team can guarantee everyone loads the same linting or review plugin, without a teammate’s personal defaults silently opting them out.

How it connects to the rest of the system

enabledPlugins does not stand alone:

• /plugin within Claude Code or claude plugin from the command line is the front end. When you install a plugin and pick a scope, /plugin writes the true entry into the settings.json for that scope. Disabling from the Installed tab flips it to false.
• extraKnownMarketplaces is where the @marketplace-name half comes from. A plugin can only be enabled if Claude Code knows the marketplace that supplies it.
• Skills ride along. Enabling a plugin makes all of its skills available; disabling the plugin removes all of them at once. There is no way for the separate skillOverrides setting to bring back a skill from a plugin you have switched off.

Takeaways and action points

• enabledPlugins maps plugin@marketplace to true or false; an absent plugin defers to its own defaultEnabled.
• Absent is not off — a plugin can be active without appearing in your settings at all.
• Project scope outranks user scope, so use .claude/settings.local.json when you need to opt out of a project-enabled plugin on your machine.
• Let /plugin edit the block for you; read the block yourself when you need to understand why a plugin is or is not loading.

Dear fellow developer, thank you for reading this article about how enabledPlugins works in Claude Code. Until next time, TheJavaGuy salutes you 👋!