[BUG] Cowork plugin browser does not honor `displayName` field (CLI works, UI parity gap)

Resolved 💬 1 comment Opened May 19, 2026 by cristinaiftode Closed Jun 18, 2026

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 displayName field in plugin.json / marketplace.json is documented as the human-readable name shown in plugin UI surfaces (added in Claude Code v2.1.143). The Claude Code CLI honors it, but the Cowork plugin browser UI does not — it still derives the title from the humanized slug.

This causes a parity gap between CLI and Cowork for plugin authors who want a polished display name.

What Should Happen?

In the Cowork plugin browser (Customize → Browse plugins, and the "Your organization" tab), the plugin title should render the displayName value when present:

My Plugin Display Name

Error Messages/Logs

Steps to Reproduce

Actual behavior

Cowork shows the slug-derived title instead:

My plugin slug

The description field on the same entry renders correctly with updated content, confirming the manifest is being fetched and parsed — only the title falls back to the slug.

Reproduction

  1. Author a plugin manifest with both name (slug) and displayName (human-readable) fields:

.claude-plugin/plugin.json
``json
{
"name": "my-plugin-slug",
"displayName": "My Plugin Display Name",
"version": "1.0.0",
"description": "..."
}
``

.claude-plugin/marketplace.json (plugin entry)
``json
{
"name": "my-plugin-slug",
"displayName": "My Plugin Display Name",
"source": "./",
"description": "...",
"version": "1.0.0"
}
``

  1. Publish to a marketplace repo and load in Cowork (org plugin list).
  2. Open Cowork → Customize → Browse plugins → click the plugin.
  3. Observe: the title reads "My plugin slug" (slug-derived), not "My Plugin Display Name" (displayName). Description renders correctly.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.7196.3 (ca0c62) 2026-05-16T23:42:08.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment

  • Cowork desktop app (org-managed install)
  • Plugin loaded via the org's plugin list / marketplace
  • Manifest spec: displayName documented as supported in v2.1.143+ in plugins-reference.md

Verified working in CLI

The same manifest renders displayName correctly in the standalone Claude Code CLI /plugin picker. This is specifically a Cowork UI rendering gap, not a manifest or marketplace issue.

Workarounds considered

  • Renaming the slug — works but is a breaking change for installed users (namespace shift, soft re-install, requires org admin to update the org marketplace entry). Not viable for cosmetic-only fixes.
  • Switching the team off Cowork to CLI — possible but disproportionate cost for a label fix.

Impact

Plugin authors distributing through Cowork cannot polish their plugin's display name without resorting to slug renames (with all the namespace/install-state breakage that implies). displayName exists precisely to avoid this — Cowork honoring it would close the loop.

Suggested fix

Read displayName in Cowork's plugin browser title rendering, with the same fallback-to-name behavior the CLI uses.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗