[BUG] `/plugin` TUI shows `defaultEnabled: false` plugins as enabled (loader and CLI correctly report disabled)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

A plugin with defaultEnabled: false in its manifest and no explicit enabledPlugins entry in any settings file is displayed as enabled in the /plugin TUI, even though it is actually not loaded (its skills are not exposed) and claude plugin list correctly reports ✘ disabled.

The mismatch affects:

• the plugin rows in the /plugin list view
• the per-marketplace enabled/disabled counts
• the toggle action label in the plugin details screen — it shows "Disable plugin" for a plugin that is actually disabled

Because the details screen shows "Disable plugin", there is no way to directly enable a default-disabled plugin from the TUI. Pressing "Disable plugin" writes false to settings, which only then makes the display match reality, so the first toggle is effectively inverted.

What Should Happen?

The /plugin TUI should report the same state as the plugin loader and claude plugin list: disabled, with an "Enable plugin" action in the details screen.

Error Messages/Logs

$ claude plugin list
  ❯ my-plugin@skills-dir
    Version: 1.0.0
    Scope: project
    Path: ./.claude/skills/my-plugin
    Status: ✘ disabled    <- CLI is correct; the /plugin TUI shows this same plugin as enabled

Steps to Reproduce

1. Create a skills-directory plugin (introduced in v2.1.157) with this manifest at .claude/skills/my-plugin/.claude-plugin/plugin.json:

``json
{
"name": "my-plugin",
"version": "1.0.0",
"defaultEnabled": false
}
``

1. Make sure no settings file (user/project/local) has an enabledPlugins["my-plugin@skills-dir"] entry.
2. Start Claude Code (or run /reload-plugins).
3. Compare claude plugin list (CLI) with the /plugin TUI.

Likely root cause (from reading the bundled JS): the plugin loader falls back to the manifest when there is no user setting:

enabled = setting !== undefined ? setting !== false : manifest.defaultEnabled !== false

while the /plugin TUI computes the displayed state in several places as:

enabled = settings?.enabledPlugins?.[pluginId] !== false

i.e. "disabled only when explicitly set to false", never consulting manifest.defaultEnabled (docs: Default enablement, supported since v2.1.154). So a plugin with no user setting is always rendered as enabled, regardless of its manifest default.

Claude Model

Not sure / Multiple models (not model-related)

Is this a regression?

No, this never worked — the TUI display path appears to have never consulted defaultEnabled since the field was introduced.

Last Working Version

n/a

Claude Code Version

2.1.172 (Claude Code)

Platform

Anthropic API

Operating System

macOS 26.5 (25F71)

Terminal/Shell

Ghostty (zsh)

Additional Information

The runtime enablement logic itself is correct — only the TUI display/toggle-label computation is out of sync with it.