Summary

Allow an operator to expose already-active Codex plugins from the
workspace-directory marketplace through the existing native Codex plugin
configuration and app-policy path.

Problem to solve

OpenClaw's native Codex plugin config currently accepts only
openai-curated. Organization-scoped plugins returned only by an explicit
plugin/list workspace-marketplace query are therefore dropped before
inventory, app ownership, readiness, or approval policy can be evaluated.

This blocks deployments that use a Codex app server with private workspace
plugins even when those plugins are already installed, enabled, and expose an
accessible owned app.

Proposed solution

Reuse the existing marketplaceName and pluginName fields and downstream
native-plugin pipeline:

• accept workspace-directory as the one additional supported marketplace;
• request it only when an enabled workspace policy is configured;
• match the exact marketplace-qualified PluginSummary.id;
• reuse the returned remotePluginId for plugin/read;
• reuse current app ownership, app/list readiness, default-deny app config,
  destructive-action policy, approvals, fingerprints, and bindings; and
• never call plugin/install for workspace plugins.

V1 targets app servers implementing the marketplaceKinds request field.
Older servers fail closed through the existing missing-marketplace behavior.

Alternatives considered

• A generic arbitrary-marketplace framework: unnecessary for one known
  marketplace and would broaden the security/product surface.
• A second private-plugin config or identity model: duplicates the existing
  marketplace/name, inventory, app-policy, and binding abstractions.
• Installing or authenticating private plugins from OpenClaw: out of scope;
  lifecycle setup remains owned by Codex outside the gateway.
• Reintroducing all previously reverted first-party marketplaces: broader than
  this request and reopens the separate Computer Use/migration conflict.

Impact

Affected: operators connecting OpenClaw to a Codex app server that exposes an
organization workspace plugin catalog.

Severity: blocking for those deployments; the configured plugin cannot be
admitted today.

Frequency: deterministic whenever the selected plugin exists only in
workspace-directory.

Consequence: operators must bypass OpenClaw's native plugin policy path or
cannot use the organization plugin at all.

Evidence/examples

Live app-server inspection shows the workspace catalog is returned only when
plugin/list includes marketplaceKinds: ["workspace-directory"]. Entries
have marketplace-qualified IDs and remote detail IDs that fit the existing
PluginSummary, pluginReadParams, ownership, and app-policy abstractions.

Example config shape:

codexPlugins: {
  enabled: true,
  plugins: {
    privateData: {
      marketplaceName: "workspace-directory",
      pluginName: "private-data@workspace-directory",
      allow_destructive_actions: "ask",
    },
  },
}

Additional information

Related historical context: #82216, #82219, and #89998. This request is
intentionally narrower: it does not enable bundled or primary-runtime plugins,
does not overlap the dedicated Computer Use setup, and does not change
migration behavior.