Summary

• Problem: The secrets audit flags Codex's synthetic apiKey: "codex-app-server" (defined in extensions/codex/provider.ts) as PLAINTEXT_FOUND, even though it's not a real secret — Codex's real authentication lives inside the app-server transport.
• Why it matters: Every user who has configured the Codex harness sees a false-positive plaintext finding in openclaw secrets audit, eroding trust in the signal.
• What changed: Declared codex-app-server as a plugin-owned non-secret marker in extensions/codex/openclaw.plugin.json, and extended the existing model-auth-markers unit tests to lock in the behavior. No code changes — just the manifest and a regression test.
• What did NOT change: Audit logic, isNonSecretApiKeyMarker implementation, any other plugin's manifest. The fix flows through the same path already used by ollama-local, lmstudio-local, gcp-vertex-credentials, and minimax-oauth.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: secrets audit PLAINTEXT_FOUND for synthetic codex-app-server apiKey in models.json #69511
• This PR fixes a bug or regression

Root Cause

• Root cause: The Codex extension was added without its synthetic codex-app-server apiKey being declared as a non-secret marker on the plugin manifest, while sibling plugins (Ollama, LMStudio, Anthropic-Vertex, Minimax) already do so.
• Missing detection / guardrail: No explicit assertion that every bundled plugin which uses a synthetic apiKey value in models.json registers it through nonSecretAuthMarkers. (Out of scope for this PR, but could be a follow-up guardrail.)
• Contributing context: The audit code path (src/secrets/audit.ts:412) already guards plaintext reporting with !isNonSecretApiKeyMarker(apiKey), which in turn calls listKnownNonSecretApiKeyMarkers() — a function that aggregates markers from the plugin manifest registry via loadPluginManifestRegistry({ cache: true }).plugins.flatMap(p => p.nonSecretAuthMarkers). Adding the marker to the Codex manifest is sufficient.

Regression Test Plan

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/agents/model-auth-markers.test.ts
• Scenario the test should lock in:
  1. isNonSecretApiKeyMarker("codex-app-server") returns true.
  2. listKnownNonSecretApiKeyMarkers() includes "codex-app-server" after the manifest registry is loaded.
• Why this is the smallest reliable guardrail: the two assertions exercise both the fast-path (direct marker check) and the manifest-driven aggregation, which is exactly how the audit and the merge/auth-store flows consume it. Any future accidental removal of the marker from the Codex manifest — or a regression in the manifest registry loader that drops bundled plugin markers — fails this test.
• Existing test that already covers this (if any): src/agents/model-auth-markers.test.ts already covers the four peer markers (ollama-local, lmstudio-local, gcp-vertex-credentials, minimax-oauth). This PR extends those same tests with the Codex case.

User-visible / Behavior Changes

• openclaw secrets audit no longer reports PLAINTEXT_FOUND for Codex's synthetic providers.codex.apiKey value in models.json.
• No other user-visible changes. No new configuration options. No default changes.

Diagram

N/A — no flow change, only an additional entry in an existing allow-list loaded at plugin-registry init time.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No — codex-app-server is a synthetic literal that has always been hardcoded in extensions/codex/provider.ts; this PR just declares it as a known non-secret marker. No tokens are read, stored, or transmitted differently.
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: macOS 26.5 (Apple Silicon, also applies to Linux)
• Runtime/container: local
• Model/provider: Codex harness (extensions/codex)
• Integration/channel: openclaw secrets audit CLI
• Relevant config: models.json containing providers.codex.apiKey = "codex-app-server" (the default after Codex discovery)

Steps

1. Configure Codex provider (e.g. install the Codex extension and run a Codex-managed model once so models.json persists the provider).
2. Run openclaw secrets audit.
3. Observe finding: code: PLAINTEXT_FOUND, jsonPath: providers.codex.apiKey.

Expected

• No PLAINTEXT_FOUND entry for the Codex provider, because codex-app-server is a synthetic non-secret marker.

Actual (before this PR)

• The audit reports the synthetic value as a plaintext leak.

After this PR

• Audit no longer reports it, matching the existing behavior for ollama-local, lmstudio-local, gcp-vertex-credentials, and minimax-oauth.

Evidence

• Failing test/log before + passing after
  • The new assertions in src/agents/model-auth-markers.test.ts fail on main (with arrayContaining([…, "codex-app-server", …]) missing) and pass with this PR applied.
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios:
  • Inspected src/secrets/audit.ts to confirm the plaintext guard already calls isNonSecretApiKeyMarker.
  • Inspected src/agents/model-auth-markers.ts to confirm listKnownNonSecretApiKeyMarkers() aggregates bundled plugin manifests.
  • Confirmed the Codex plugin manifest is loaded via loadPluginManifestRegistry (checked src/plugins/manifest-registry.ts).
  • Confirmed codex-app-server is used as the synthetic value in extensions/codex/provider.ts (lines 88, 89, 117).
  • Confirmed JSON syntax of the updated manifest (python3 -c "import json; json.load(...)").
  • Confirmed the new assertions are placed next to peer markers so future regressions are obvious.
• Edge cases checked: the manifest registry cache (cache: true) is loaded at startup; no code path reads nonSecretAuthMarkers outside the registry aggregation, so no additional sites need updating.
• What I did not verify: did not run the full pnpm test:unit locally (no pnpm install on this machine); CI will run the suite.

Review Conversations

• I will reply to or resolve every bot review conversation I address in this PR.
• I will leave unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: a future plugin reuses the string codex-app-server in a non-Codex context and ends up whitelisted.
  • Mitigation: the string is intentionally Codex-branded and lives in the Codex plugin manifest. The registry aggregates from origin === "bundled" plugins only, so third-party plugins cannot injection-whitelist additional markers.