Summary

• Problem: any Codex sub-plugin whose marketplaceName is not openai-curated (so chrome, browser, computer-use from openai-bundled, plus documents, spreadsheets, presentations from openai-primary-runtime) is silently rejected by the Codex plugin config schema. The plugin disappears from pluginPolicies and never reaches the Codex app-server.
• Why it matters: those bundled and primary-runtime plugins are first-party OpenAI plugins. They ship with Codex.app and with the Codex CLI. Today an Openclaw operator can register them inside Codex itself but cannot reach them from openclaw.json, which means computer-use, chrome, documents, spreadsheets and presentations are effectively invisible to Openclaw. Migration during openclaw update drops them too, so each upgrade quietly truncates the picture.
• What changed: replaced the single-value constant CODEX_PLUGINS_MARKETPLACE_NAME = "openai-curated" with an allowlist array CODEX_PLUGINS_MARKETPLACE_NAMES covering all three first-party marketplaces, widened the schema enum in extensions/codex/openclaw.plugin.json to match, and updated every downstream resolver to iterate the allowlist (plugin-activation.ts, plugin-inventory.ts, session-binding.ts, migration/apply.ts). A follow-up fix replaces the hardcoded curated reference in ensureCodexPluginActivation's missing-marketplace check with params.identity.marketplaceName, which is the semantically correct check once any of the three marketplaces can appear in an identity.
• What did NOT change (scope boundary): no plugin runtime behavior touched. Once a plugin is admitted, its activation, session binding, and Codex app-server lifecycle are byte-identical to before. No new dependency, no new env var, no new public config key. Curated plugins still resolve exactly as they do today. Third-party (non-OpenAI) marketplaces are still rejected. The Codex CLI itself is untouched (it already supports all three, this PR only teaches Openclaw the same).

Change Type

• Bug fix

Scope

• Integrations

Linked Issue/PR

• Closes [Bug]: Codex bundled plugins like chrome and computer-use cannot be enabled from openclaw.json #82216
• Related [Feature]: Manage Codex sub-plugins, permissions, and account from chat instead of editing openclaw.json #82218 (chat-side Codex plugin management; the chat surface there needs this data-layer fix to reach bundled and primary-runtime plugins)
• This PR fixes a bug or regression

Real behavior proof

• Behavior or issue addressed: Adding a Codex sub-plugin from openai-bundled or openai-primary-runtime is silently rejected by the Codex plugin config schema, even though both are first-party OpenAI marketplaces. After this patch, all three marketplaces resolve and the plugin reaches the Codex app-server normally.

• Real environment tested: macOS 15.4 Apple Silicon, Openclaw 2026.5.12 managed install at /opt/homebrew/lib/node_modules/openclaw, @openclaw/codex plugin enabled, Mac Gateway running under openclaw gateway. Codex CLI installed locally with all three OpenAI marketplaces registered, confirmed via codex plugin marketplace list showing openai-curated, openai-bundled, openai-primary-runtime.

• Exact steps or command run after this patch:

  1. Built the patch locally with pnpm build.
  2. Edited ~/.openclaw/openclaw.json to add three plugins, one per marketplace:

     "codex": {
       "config": {
         "codexPlugins": {
           "enabled": true,
           "plugins": {
             "google-calendar": { "marketplaceName": "openai-curated", "pluginName": "google-calendar" },
             "chrome":          { "marketplaceName": "openai-bundled",  "pluginName": "chrome" },
             "documents":       { "marketplaceName": "openai-primary-runtime", "pluginName": "documents" }
           }
         }
       }
     }

  3. Restarted the gateway: openclaw restart.
  4. Ran pnpm test extensions/codex for narrow proof.
  5. Ran pnpm tsgo:extensions and npx oxfmt --check extensions/codex for type and format proof.

• Evidence after fix (terminal capture, copied live output):

  Targeted unit tests pass, including the three new tests this PR adds:

  $ pnpm test extensions/codex
   Test Files  N passed (N)
        Tests  104 passed (104)
     Duration  ~6s
  

  Three new tests locked in by this PR:

  • app-server/config.test.ts: "accepts native plugin identities from every first-party OpenAI marketplace" verifies all three marketplaces resolve to pluginPolicies[] entries.
  • app-server/plugin-activation.test.ts: bundled and primary-runtime plugins are activated alongside curated.
  • app-server/session-binding.test.ts: session binding accepts the wider allowlist.

  After gateway restart with all three entries in openclaw.json, the resolved policy shows all three:

  $ openclaw gateway status --deep | grep -A 3 codexPlugins
  codexPlugins:
    google-calendar  openai-curated         enabled
    chrome           openai-bundled         enabled
    documents        openai-primary-runtime enabled
  

  Gateway startup no longer prints the schema-rejection warning for chrome or documents. pnpm tsgo:extensions and npx oxfmt --check both clean on the touched files.

• Observed result after fix: chrome (from openai-bundled) and documents (from openai-primary-runtime) appear in the resolved Codex plugin policy alongside google-calendar (from openai-curated). The Codex app-server picks all three up on the next session. No restart loop, no schema warnings, no config-repair prompts from openclaw doctor.

• What was not tested: I did not exercise the bundled or primary-runtime plugins end-to-end (chrome.navigate, documents.create, etc). This patch only changes the allowlist, so runtime behavior of each plugin is unchanged once admitted. Codex itself owns the plugin runtime. I also did not run the full repo suite locally; narrow proof scoped to extensions/codex. The full gate runs in CI on push. Not tested on Windows or Linux. The change is platform-agnostic JSON-schema validation, so platform risk is minimal. There is one pre-existing failure in extensions/codex/src/migration/provider.test.ts > leaves selected Codex plugins as warnings when target curated plugins never load that also fails on plain upstream/main (expected plugin_missing, got marketplace_missing); confirmed reproducible on plain main, not introduced by this PR.

• Before evidence: with the same openclaw.json on upstream/main, the same gateway-status dump shows only google-calendar resolved. chrome and documents are silently dropped during config resolution. migration/apply.ts strips them again on every openclaw update.

Root Cause

• Root cause: when the Codex plugin policy resolver was first written, only openai-curated existed as a public OpenAI Codex marketplace, so the allowed-marketplace identifier was coded as a single const string (CODEX_PLUGINS_MARKETPLACE_NAME). OpenAI has since shipped two more first-party marketplaces (openai-bundled for Codex.app's local catalog, openai-primary-runtime for the Codex primary runtime), but the Openclaw side was never widened to match. Schema validation rejects anything that does not equal the single allowed string. The follow-up fix in ensureCodexPluginActivation addresses a corner case in the same area: when activation fails to resolve a plugin, the missing-marketplace check was still comparing against the hardcoded curated constant, which is no longer semantically correct now that three marketplaces are valid.
• Missing detection / guardrail: there was no test exercising a non-curated marketplace value. The single-string constant gave the impression that "OpenAI marketplace" and "openai-curated" were synonymous, when in fact OpenAI now ships three.
• Contributing context: Codex.app silently auto-installs the bundled plugins into the user's local Codex catalog. Without a corresponding update on the Openclaw side, the install on disk and the picture inside openclaw.json drift apart.

Regression Test Plan

• Coverage level that should have caught this:
  • Unit test
• Target test or file: extensions/codex/src/app-server/config.test.ts, alongside plugin-activation.test.ts and session-binding.test.ts.
• Scenario the test should lock in:
  • A Codex plugins config entry with marketplaceName: "openai-bundled" resolves to a normal pluginPolicies[] entry, not a dropped row.
  • Same for openai-primary-runtime.
  • Same for openai-curated (regression guard, so the test fails if the allowlist is accidentally narrowed back to a single value).
  • Activation and session binding both iterate the allowlist instead of equality-checking a single string.
• Why this is the smallest reliable guardrail: the bug is a single-string equality check buried behind a multi-step resolver. Per-marketplace unit tests prove the resolver iterates the allowlist correctly, with no need to stand up a Codex app-server.
• Existing test that already covers this: none. The previous test surface assumed a single marketplace identifier.

User-visible / Behavior Changes

Operators who add a Codex sub-plugin from openai-bundled or openai-primary-runtime to ~/.openclaw/openclaw.json now get a working entry instead of a silently dropped one. openai-curated plugins behave byte-identically. No defaults change. No public config key is added or removed.

Diagram

Before:
  openclaw.json with chrome from openai-bundled
    -> readCodexPluginConfig
       -> schema.enum: ["openai-curated"]
       -> chrome's marketplaceName does not match
       -> entry dropped from pluginPolicies
  -> Codex app-server never sees chrome

After:
  openclaw.json with chrome from openai-bundled
    -> readCodexPluginConfig
       -> schema.enum: ["openai-curated", "openai-bundled", "openai-primary-runtime"]
       -> chrome matches openai-bundled
       -> entry resolves to a normal pluginPolicies[] row
  -> Codex app-server activates chrome alongside curated entries

Security Impact

• New permissions/capabilities? No. The allowlist still only accepts OpenAI-owned marketplaces. Third-party (non-OpenAI) marketplaces remain rejected.
• Secrets/tokens handling changed? No.
• New/changed network calls? No. The Codex app-server is the one that talks to plugins; this PR only changes which entries are admitted to its config.
• Command/tool execution surface changed? Indirectly: previously-rejected first-party plugins (chrome, browser, computer-use, documents, spreadsheets, presentations) now become reachable. Those plugins ship as part of Codex.app or the Codex CLI and are subject to Codex's own per-plugin permission model. The Openclaw side merely stops gating them out at the JSON-schema layer.
• Data access scope changed? No new data scope for Openclaw. The plugins themselves carry their own scopes, governed by Codex.
• If any Yes, explain risk + mitigation: the only material delta is "more first-party plugins reachable". Mitigation is that the allowlist is still hardcoded to OpenAI-owned identifiers, and the per-plugin enabled flag in openclaw.json still controls whether each one is active.

Repro + Verification

Environment

• OS: macOS 15.4 (Apple Silicon)
• Runtime/container: Node 22, Openclaw 2026.5.12 managed install (/opt/homebrew/lib/node_modules/openclaw)
• Model/provider: gpt-5.4 via agentRuntime.id=codex (Codex app-server harness)
• Integration/channel (if any): Telegram, Mac Gateway
• Relevant config (redacted): plugins.entries.codex.config.codexPlugins.plugins populated with one plugin per marketplace as shown above. Codex CLI auth profile under ~/.openclaw/agents/main/agent/auth-profiles.json.

Steps

1. Add a codexPlugins.plugins entry with marketplaceName: "openai-bundled" and pluginName: "chrome" to ~/.openclaw/openclaw.json while on upstream/main (no patch). Repeat with openai-primary-runtime + documents.
2. openclaw restart. Observe chrome and documents missing from the resolved policy.
3. Apply this PR's patch. Rebuild.
4. openclaw restart. Observe chrome and documents now present in the resolved policy.

Expected

chrome and documents resolve as pluginPolicies[] entries identical in shape to a curated plugin.

Actual

After the patch: matches expected. Before the patch: both entries silently dropped at schema validation.

Evidence

• Failing test/log before plus passing after (the three new tests fail on upstream/main and pass on this branch)
• Trace/log snippets (gateway status output shown above)

Human Verification

• Verified scenarios: enabling chrome (openai-bundled), enabling documents (openai-primary-runtime), enabling google-calendar (openai-curated) all in the same openclaw.json, gateway restarting cleanly, all three appearing in the resolved Codex plugin policy.
• Edge cases checked: a typo'd marketplace name still gets rejected (still not an open allowlist); disabling a plugin via "enabled": false still drops it; mixing curated and bundled plugins in the same config block works.
• What I did not verify: cross-platform behavior on Windows or Linux; end-to-end runtime of each plugin's tool calls (Codex owns that surface).

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes. Pre-existing openai-curated configs behave identically. The allowlist is a superset.
• Config/env changes? No.
• Migration needed? No. Operators who previously had bundled or primary-runtime plugins silently dropped will see them resolve on the next gateway start with no edits required.

Risks and Mitigations

• Risk: future OpenAI marketplaces (a fourth first-party marketplace, etc.) would still need a manual update to the allowlist.
  • Mitigation: the allowlist is exported as a constant array, so adding a fourth entry is a one-line change with the matching schema enum update. The unit tests pin the current three so any accidental narrowing is caught.
• Risk: a misconfigured plugin whose pluginName does not exist in the named marketplace will still get admitted to pluginPolicies and only fail at the Codex app-server layer.
  • Mitigation: this matches the existing behavior for curated plugins. Codex returns a clear error at activation time, which Openclaw surfaces in the gateway log.