[BUG]

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?

Desktop app: clicking a plugin's settings gear in Directory → Plugins closes the dialog and navigates away from Cowork

Summary

In the Claude desktop app, opening Directory → Plugins, selecting a marketplace, and
clicking the gear icon on any plugin card does not open that plugin's settings.
Instead the Directory dialog closes entirely and the app navigates out of the Cowork
panel to the main chat home screen.

The app does not crash — no crash dump is produced and the main process continues logging
normally — so this appears to be a renderer-side state/navigation fault rather than a
process failure.

Environment

| | |
|---|---|
| Claude desktop app | 1.28929.0 |
| Bundled Claude Code | 2.1.227 |
| Separately installed Claude Code CLI | 2.1.228 |
| macOS | 26.3 (build 25D125) |
| Arch | arm64 (Apple silicon) |

Plugins installed from a private third-party GitHub marketplace (user scope, 3 plugins).

Steps to reproduce

1. Open the desktop app with a Cowork session active.
2. Open Directory → Plugins.
3. Select the Code tab, then a marketplace chip.
4. Click the gear icon on any plugin card.

Expected

The plugin's settings/detail view opens within the Directory dialog.

Actual

• The Directory dialog closes.
• The app leaves the Cowork panel and lands on the opening chat screen.
• No settings view is shown for the plugin, and no error is surfaced in the UI.

Reproduces on every plugin card in the marketplace, not just one.

Evidence

No crash occurred. Nothing was written to ~/Library/Application Support/Claude/Crashpad
or ~/Library/Logs/DiagnosticReports at the time of the click, and main.log continued
logging normally afterwards.

Listener-cleanup warnings in ~/Library/Logs/Claude/claude.ai-web.log. Three separate
eIPC channels each reach exactly 11 accumulated listeners while navigating this UI:

2026-08-12 12:46:35 [warn] MaxListenersExceededWarning: Possible EventEmitter memory leak
  detected. 11 …_$_claude.web_$_CustomPlugins_$_localOrgPluginsSynced listeners added.
2026-08-12 12:50:44 [warn] MaxListenersExceededWarning: Possible EventEmitter memory leak
  detected. 11 …_$_claude.web_$_LocalAgentModeSessions_$_sessionsBridgeStatus_$store$_update
  listeners added.
2026-08-12 12:54:40 [warn] MaxListenersExceededWarning: … CustomPlugins_$_localOrgPluginsSynced …
2026-08-12 12:54:40 [warn] MaxListenersExceededWarning: … LocalAgentModeSessions_$_sessionsBridgeStatus …
2026-08-12 12:54:44 [warn] MaxListenersExceededWarning: … claude.settings_$_AppPreferences_$_preferencesChanged …

The same CustomPlugins_$_localOrgPluginsSynced warning also appears on an earlier date
(2026-08-07 23:40:08), so the accumulation is not a one-off.

I want to be clear that this is correlation, not a diagnosis — the leak spans at least
three channels (CustomPlugins, LocalAgentModeSessions, AppPreferences), so it looks
like a general "listeners not torn down on unmount" pattern across the eIPC bridge rather
than something specific to the plugins panel. It may be the mechanism behind a stale
handler firing and navigating the window, or it may be an unrelated symptom of the same
component-lifecycle issue. The AppPreferences_$_preferencesChanged warning landing four
seconds after the plugins one seemed worth including given the dialog in question is a
settings surface.

Memory at the time, in case it is relevant to renderer stability: renderer RSS ~650MB,
whole-tree RSS ~2.9GB, system free memory reported as low (~130–150MB raw).

Impact

The plugin settings view is unreachable from the desktop app, and the navigation side
effect loses the user's place in their Cowork session. Per-plugin configuration and the
marketplace-level auto-update toggle both appear to be unreachable through this path.

Workarounds that do function:

• The Update button on the plugin detail page (reached by clicking the plugin name

rather than the gear) works.

• claude plugin marketplace update <name> and claude plugin update <plugin> from the

CLI work.

• The marketplace auto-update toggle is reachable via /plugin marketplace in an

interactive CLI session.

Note on the two installed versions

The desktop app runs bundled Claude Code 2.1.227 while a separate CLI install is at
2.1.228. Menu affordances present in the CLI build (for example the marketplace
toggle-auto-update action) are not visibly present in the app's plugin UI. Flagging in
case the two surfaces are expected to be at parity.

What Should Happen?

Desktop app: clicking a plugin's settings gear in Directory → Plugins closes the dialog and navigates away from Cowork

Summary

In the Claude desktop app, opening Directory → Plugins, selecting a marketplace, and
clicking the gear icon on any plugin card does not open that plugin's settings.
Instead the Directory dialog closes entirely and the app navigates out of the Cowork
panel to the main chat home screen.

The app does not crash — no crash dump is produced and the main process continues logging
normally — so this appears to be a renderer-side state/navigation fault rather than a
process failure.

Environment

| | |
|---|---|
| Claude desktop app | 1.28929.0 |
| Bundled Claude Code | 2.1.227 |
| Separately installed Claude Code CLI | 2.1.228 |
| macOS | 26.3 (build 25D125) |
| Arch | arm64 (Apple silicon) |

Plugins installed from a private third-party GitHub marketplace (user scope, 3 plugins).

Steps to reproduce

1. Open the desktop app with a Cowork session active.
2. Open Directory → Plugins.
3. Select the Code tab, then a marketplace chip.
4. Click the gear icon on any plugin card.

Expected

The plugin's settings/detail view opens within the Directory dialog.

Actual

• The Directory dialog closes.
• The app leaves the Cowork panel and lands on the opening chat screen.
• No settings view is shown for the plugin, and no error is surfaced in the UI.

Reproduces on every plugin card in the marketplace, not just one.

Evidence

No crash occurred. Nothing was written to ~/Library/Application Support/Claude/Crashpad
or ~/Library/Logs/DiagnosticReports at the time of the click, and main.log continued
logging normally afterwards.

Listener-cleanup warnings in ~/Library/Logs/Claude/claude.ai-web.log. Three separate
eIPC channels each reach exactly 11 accumulated listeners while navigating this UI:

2026-08-12 12:46:35 [warn] MaxListenersExceededWarning: Possible EventEmitter memory leak
  detected. 11 …_$_claude.web_$_CustomPlugins_$_localOrgPluginsSynced listeners added.
2026-08-12 12:50:44 [warn] MaxListenersExceededWarning: Possible EventEmitter memory leak
  detected. 11 …_$_claude.web_$_LocalAgentModeSessions_$_sessionsBridgeStatus_$store$_update
  listeners added.
2026-08-12 12:54:40 [warn] MaxListenersExceededWarning: … CustomPlugins_$_localOrgPluginsSynced …
2026-08-12 12:54:40 [warn] MaxListenersExceededWarning: … LocalAgentModeSessions_$_sessionsBridgeStatus …
2026-08-12 12:54:44 [warn] MaxListenersExceededWarning: … claude.settings_$_AppPreferences_$_preferencesChanged …

The same CustomPlugins_$_localOrgPluginsSynced warning also appears on an earlier date
(2026-08-07 23:40:08), so the accumulation is not a one-off.

I want to be clear that this is correlation, not a diagnosis — the leak spans at least
three channels (CustomPlugins, LocalAgentModeSessions, AppPreferences), so it looks
like a general "listeners not torn down on unmount" pattern across the eIPC bridge rather
than something specific to the plugins panel. It may be the mechanism behind a stale
handler firing and navigating the window, or it may be an unrelated symptom of the same
component-lifecycle issue. The AppPreferences_$_preferencesChanged warning landing four
seconds after the plugins one seemed worth including given the dialog in question is a
settings surface.

Memory at the time, in case it is relevant to renderer stability: renderer RSS ~650MB,
whole-tree RSS ~2.9GB, system free memory reported as low (~130–150MB raw).

Impact

The plugin settings view is unreachable from the desktop app, and the navigation side
effect loses the user's place in their Cowork session. Per-plugin configuration and the
marketplace-level auto-update toggle both appear to be unreachable through this path.

Workarounds that do function:

• The Update button on the plugin detail page (reached by clicking the plugin name

rather than the gear) works.

• claude plugin marketplace update <name> and claude plugin update <plugin> from the

CLI work.

• The marketplace auto-update toggle is reachable via /plugin marketplace in an

interactive CLI session.

Note on the two installed versions

The desktop app runs bundled Claude Code 2.1.227 while a separate CLI install is at
2.1.228. Menu affordances present in the CLI build (for example the marketplace
toggle-auto-update action) are not visibly present in the app's plugin UI. Flagging in
case the two surfaces are expected to be at parity.

Error Messages/Logs

Steps to Reproduce

Desktop app: clicking a plugin's settings gear in Directory → Plugins closes the dialog and navigates away from Cowork

Summary

In the Claude desktop app, opening Directory → Plugins, selecting a marketplace, and
clicking the gear icon on any plugin card does not open that plugin's settings.
Instead the Directory dialog closes entirely and the app navigates out of the Cowork
panel to the main chat home screen.

The app does not crash — no crash dump is produced and the main process continues logging
normally — so this appears to be a renderer-side state/navigation fault rather than a
process failure.

Environment

| | |
|---|---|
| Claude desktop app | 1.28929.0 |
| Bundled Claude Code | 2.1.227 |
| Separately installed Claude Code CLI | 2.1.228 |
| macOS | 26.3 (build 25D125) |
| Arch | arm64 (Apple silicon) |

Plugins installed from a private third-party GitHub marketplace (user scope, 3 plugins).

Steps to reproduce

1. Open the desktop app with a Cowork session active.
2. Open Directory → Plugins.
3. Select the Code tab, then a marketplace chip.
4. Click the gear icon on any plugin card.

Expected

The plugin's settings/detail view opens within the Directory dialog.

Actual

• The Directory dialog closes.
• The app leaves the Cowork panel and lands on the opening chat screen.
• No settings view is shown for the plugin, and no error is surfaced in the UI.

Reproduces on every plugin card in the marketplace, not just one.

Evidence

No crash occurred. Nothing was written to ~/Library/Application Support/Claude/Crashpad
or ~/Library/Logs/DiagnosticReports at the time of the click, and main.log continued
logging normally afterwards.

Listener-cleanup warnings in ~/Library/Logs/Claude/claude.ai-web.log. Three separate
eIPC channels each reach exactly 11 accumulated listeners while navigating this UI:

2026-08-12 12:46:35 [warn] MaxListenersExceededWarning: Possible EventEmitter memory leak
  detected. 11 …_$_claude.web_$_CustomPlugins_$_localOrgPluginsSynced listeners added.
2026-08-12 12:50:44 [warn] MaxListenersExceededWarning: Possible EventEmitter memory leak
  detected. 11 …_$_claude.web_$_LocalAgentModeSessions_$_sessionsBridgeStatus_$store$_update
  listeners added.
2026-08-12 12:54:40 [warn] MaxListenersExceededWarning: … CustomPlugins_$_localOrgPluginsSynced …
2026-08-12 12:54:40 [warn] MaxListenersExceededWarning: … LocalAgentModeSessions_$_sessionsBridgeStatus …
2026-08-12 12:54:44 [warn] MaxListenersExceededWarning: … claude.settings_$_AppPreferences_$_preferencesChanged …

The same CustomPlugins_$_localOrgPluginsSynced warning also appears on an earlier date
(2026-08-07 23:40:08), so the accumulation is not a one-off.

I want to be clear that this is correlation, not a diagnosis — the leak spans at least
three channels (CustomPlugins, LocalAgentModeSessions, AppPreferences), so it looks
like a general "listeners not torn down on unmount" pattern across the eIPC bridge rather
than something specific to the plugins panel. It may be the mechanism behind a stale
handler firing and navigating the window, or it may be an unrelated symptom of the same
component-lifecycle issue. The AppPreferences_$_preferencesChanged warning landing four
seconds after the plugins one seemed worth including given the dialog in question is a
settings surface.

Memory at the time, in case it is relevant to renderer stability: renderer RSS ~650MB,
whole-tree RSS ~2.9GB, system free memory reported as low (~130–150MB raw).

Impact

The plugin settings view is unreachable from the desktop app, and the navigation side
effect loses the user's place in their Cowork session. Per-plugin configuration and the
marketplace-level auto-update toggle both appear to be unreachable through this path.

Workarounds that do function:

• The Update button on the plugin detail page (reached by clicking the plugin name

rather than the gear) works.

• claude plugin marketplace update <name> and claude plugin update <plugin> from the

CLI work.

• The marketplace auto-update toggle is reachable via /plugin marketplace in an

interactive CLI session.

Note on the two installed versions

The desktop app runs bundled Claude Code 2.1.227 while a separate CLI install is at
2.1.228. Menu affordances present in the CLI build (for example the marketplace
toggle-auto-update action) are not visibly present in the app's plugin UI. Flagging in
case the two surfaces are expected to be at parity.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

The desktop app runs bundled Claude Code 2.1.227 while a separate CLI install is at 2.1.228

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_