[BUG] macOS desktop app ignores project-level `enabledPlugins` — every project shows an identical plugin list (CLI and Windows work)

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?

The Claude desktop app on macOS resolves enabledPlugins only from the user-level ~/.claude/settings.json. It ignores enabledPlugins declared in a project's .claude/settings.json and .claude/settings.local.json, even though it correctly honours other keys from those same files.

The visible result is that the plugin menu (+ → Plugin) shows an identical list in every project, regardless of each project's own plugin configuration. There is no error and no warning — the project-scoped plugins are simply absent.

The CLI on the same machine, launched from the same directory with the same config files, merges all levels correctly and registers all the plugins. The Windows desktop app also behaves correctly.

Environment

• Claude desktop app 1.24012.9 (Electron 42.7.0, Node 24.18.0), macOS arm64
• Claude CLI on the same machine: works correctly (control case)
• Claude desktop app on Windows: works correctly (control case)

Reproduction

Two projects with deliberately different plugin configurations.

Project A (crosscms) — <projectA>/.claude/settings.json:

{
  "enabledPlugins": { "marketing-skills@marketingskills": true }
}

<projectA>/.claude/settings.local.json:

{
  "enabledPlugins": { "laravel@laravel": true, "impeccable@impeccable": true }
}

Project B — no project-level enabledPlugins at all.

User level — ~/.claude/settings.json:

{ "enabledPlugins": { "mattpocock-skills@mattpocock": true } }

~/.claude/plugins/installed_plugins.json contains the matching install records with the correct values:

• mattpocock-skills@mattpocock — "scope": "user", no projectPath
• marketing-skills@marketingskills — "scope": "project", projectPath = project A
• impeccable@impeccable — "scope": "local", projectPath = project A
• laravel@laravel — "scope": "local", projectPath = project A

Steps:

1. Open project A in the macOS desktop app.
2. Click + in the composer, then Plugin.
3. Open project B and repeat.

Actual behaviour

Both projects show an identical submenu containing only mattpocock-skills — the sole plugin enabled at user level. Every plugin enabled through a project-level settings file is silently missing from project A.

Ruled out during diagnosis

• Not a path-resolution mismatch. pwd and pwd -P in the project directory return a string identical to the stored projectPath. No symlink or firmlink indirection (the project is not under an iCloud-synced folder), no case difference, and no drive letters on macOS. This distinguishes it from #74912.
• Not a corrupted or unparseable config. installed_plugins.json parses as valid JSON, and the plugin payloads are present under ~/.claude/plugins/cache/.
• Not a bad scope record. The install records carry the correct scope and projectPath, and the CLI reads the same file successfully.
• Not a general failure to read project settings. The permissions entries from the very same two project files are applied correctly by the desktop app. Only enabledPlugins is dropped.
• Affects both scopes. scope: "project" and scope: "local" entries fail identically.

Impact

Per-project plugin configuration is unusable from the macOS desktop app. Users who scope plugins per project — the documented purpose of the --scope project flag, and a workflow the CLI supports today — see none of them in the GUI, with no signal that the configuration was ignored. The only way to make a plugin visible in the app is to promote it to user scope, which forces it on for every project.

Related

• #74612 — the same divergence reported for the VS Code extension on Windows. I added the macOS desktop-app evidence there as a comment; filing this separately because the affected surface and platform are different.
• #74912 — proposes case-sensitive projectPath comparison (Windows drive letters) as the cause. That explanation cannot cover this case, since the paths here match exactly.
• #62174 — closed as not planned, treating per-project enabledPlugins as a feature request. The CLI does honour project-level values today, so the desktop app is inconsistent with shipped behaviour rather than missing a feature.

What Should Happen?

The macOS desktop app should merge enabledPlugins across user, project and local settings files, exactly as the CLI does when launched from the same directory.

Concretely, for the setup above:

• Project A's plugin menu should list marketing-skills, laravel, impeccable and mattpocock-skills.
• Project B's plugin menu should list only mattpocock-skills.

Failing that, the app should at minimum surface a warning when it encounters enabledPlugins in a project settings file that it is not going to honour, rather than dropping it silently.

Error Messages/Logs

Steps to Reproduce

Prerequisite: two projects, A and B, with different plugin configurations.

1. In project A's directory, create .claude/settings.json:

``json
{
"enabledPlugins": { "marketing-skills@marketingskills": true }
}
``

1. In the same directory, create .claude/settings.local.json:

``json
{
"enabledPlugins": { "laravel@laravel": true, "impeccable@impeccable": true }
}
``

1. Leave project B with no project-level enabledPlugins.

1. Enable exactly one plugin at user level in ~/.claude/settings.json:

``json
{ "enabledPlugins": { "mattpocock-skills@mattpocock": true } }
``

1. Confirm the install records exist and are correct in ~/.claude/plugins/installed_plugins.json (scope = project / local, projectPath = project A's absolute path).

1. Verify the CLI behaves correctly: cd into project A and run claude plugin list. All four plugins are reported.

1. Open project A in the macOS desktop app. Click + in the message composer, then Plugin.

1. Observe: the submenu lists only mattpocock-skills. The three project-level plugins are missing, with no error or warning.

1. Open project B and repeat step 7. The submenu is identical, despite the two projects having different configurations.

Control checks that isolate the failure:

1. Confirm the app does read those same project files: the permissions entries from step 1 and 2 are applied in project A's sessions. Only enabledPlugins is dropped.

1. Confirm there is no path mismatch: cd into project A and run pwd && pwd -P. Both print a string identical to the projectPath stored in installed_plugins.json.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Exact version unknown — worked correctly until roughly four releases before 1.22209.3 (build babe11)

Claude Code Version

Claude desktop app for macOS 1.24012.9 (Electron 42.7.0, Node 24.18.0). The bundled Claude Code runtime on the same machine handles the same config correctly when used from the CLI, which is the control case for this report.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Note on scope. This is the Claude desktop app for macOS, not the Claude Code CLI. I am filing it here because the repository tracks desktop-app issues (e.g. #72025, #72179), and because the defect is precisely a divergence from Claude Code's own documented behaviour: the CLI honours project-level enabledPlugins and the desktop app does not, on the same machine, in the same directory, reading the same files.

Previous report. I filed #79376 earlier describing the user-visible symptom. That report was auto-closed as invalid by the triage bot without human review. It was also based on an incorrect root-cause guess on my part — I described the app as showing plugins belonging to other projects, when in fact it shows only user-scoped plugins and drops project-scoped ones entirely. This report supersedes it with the corrected diagnosis and the control checks that establish it.

Relationship to #74612. That report describes the same divergence for the VS Code extension on Windows. I have added the macOS desktop-app evidence there as a comment. Filing separately here because the affected surface and platform differ, and because the leading hypothesis in that thread (#74912, case-sensitive drive-letter comparison in projectPath) cannot explain the macOS case, where the paths match exactly.

Screenshots of the plugin submenu in both projects, and the full contents of installed_plugins.json, are available on request. Project and plugin paths in this report have been anonymised; the plugin names are the real ones.