OpenClaw drafts package-owned categories for its plugin workspace

OpenClaw's plugin workspace work gained four proposal layers on September 9: package-owned categories, exact-version catalog enrichment, grouped installed inventories and unified detail tabs. The product direction is a clearer place to understand what is installed, rather than one dense panel mixing plugins, skills, workshop tools and MCP servers. The architectural choice beneath the layout is equally important: marketplace metadata may enrich a page, but it should not become the authority for local access or lifecycle controls.

The facts

- The category proposal defines an optional ordered categories field, with primary and multi-category semantics owned by the package manifest. - Catalog enrichment uses canonical package identity and exact version, replacing steady-state category inference in OpenClaw. - The installed view groups a plugin once under its primary category and expands the full grouped inventory through View all. - The detail-shell proposal renders only supported, non-empty component tabs and moves needs-setup attention to Configuration. - Local configuration, enablement, access, lifecycle and uninstall remain authoritative while marketplace metadata is optional enrichment. - The underlying workspace proposal still discloses dependency authorization and landing approval requirements; these open layers are not a released interface.

Why it matters

Plugin interfaces can blur three different facts: a package exists in a catalog, a version is installed, and its capabilities are actually configured and permitted. A familiar marketplace shell does not resolve that ambiguity by itself. Package-owned categories and exact-version metadata can make the description less speculative, while local controls preserve the distinction between discovery and authority. For operators managing a larger inventory, that is more useful than adding another attractive card whose enabled state is unclear.

Current

Inspected on 2026-09-09. The OpenClaw stable-release baseline is v2026.9.3 published 2026-09-08T14:15:53Z. The main source was open (not merged) when captured. Release metadata is a version boundary; an open proposal, a merged mainline change and a packaged release remain different states.

Evidence

The primary evidence is openclaw/openclaw PR #142710 (https://github.com/openclaw/openclaw/pull/142710). Supporting context comes from openclaw/openclaw PR #142711 (https://github.com/openclaw/openclaw/pull/142711); openclaw/openclaw PR #142712 (https://github.com/openclaw/openclaw/pull/142712); openclaw/openclaw PR #142713 (https://github.com/openclaw/openclaw/pull/142713); openclaw/openclaw PR #135839 (https://github.com/openclaw/openclaw/pull/135839). These pages were inspected directly. Related project records explain the source cluster; they are not independent replications of contributor test claims.

Operator take

Follow the complete stack rather than evaluating one category field in isolation. A review should include an installed package missing catalog metadata, an offline registry, an empty component inventory and a plugin needing setup. Verify that the page still exposes the locally actionable control and does not invent a tab merely because the marketplace knows a feature name. The earlier workspace describes dense-inventory browser fixtures, but those fixtures are evidence of layout testing, not a count of real users or production plugins. The fresh layers should be judged against their own exact heads and landing conditions.

Caveat

All selected plugin proposals were open when captured. Reported backend, UI and browser checks belong to their authors and do not remove the workspace's explicit dependency and approval blockers. ClawHub enrichment is metadata, not a new permission grant, and no claim is made that today's stable build already contains these screens.