Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

The gateway can start in a Codex-configured setup without activating the Codex agent harness plugin, even when the config clearly requests the native Codex harness.

This is separate from model catalog registration failures like Unknown model: codex/gpt-5.4. This issue is specifically about ensuring the Codex harness owner plugin is included in startup activation when Codex is the configured embedded harness runtime.

Parent tracker: #66251

Steps to reproduce

1. Configure an agent to use the native Codex harness, for example:

   {
     "agents": {
       "defaults": {
         "model": {
           "primary": "codex/gpt-5.4"
         },
         "embeddedHarness": {
           "runtime": "codex",
           "fallback": "none"
         }
       }
     }
   }

2. Start the gateway.

3. Trigger a Codex-backed agent turn or gateway warmup.

4. Observe that the Codex harness may not be registered even though Codex appears in plugin discovery/diagnostics.

Expected behavior

When config references the Codex native harness, the gateway startup path should activate the plugin that owns the codex agent harness before agent/channel startup proceeds.

This should work when Codex is required through either:

• a codex/* model reference
• agents.defaults.embeddedHarness.runtime = "codex"
• a per-agent embedded harness runtime override

Actual behavior

The gateway startup plugin selection can omit the Codex harness owner plugin. Plugin inspection can make Codex look available, but diagnostic loading is not equivalent to live runtime registration.

In strict Codex-only configs with fallback disabled, this can surface as errors like:

Requested agent harness "codex" is not registered and PI fallback is disabled.

OpenClaw version

2026.4.10 / 2026.4.11 reports, plus current main investigation

Operating system

macOS and Linux reports

Install method

npm/global CLI and local source investigation

Model

codex/gpt-5.4

Provider / routing chain

OpenClaw -> bundled codex plugin -> Codex app-server

Additional provider/model setup details

NOT_ENOUGH_INFO

Logs, screenshots, and evidence

Scope boundary

This issue should not track general provider catalog registration problems. Those belong in #64938.

This issue is specifically about startup activation of the plugin that owns the Codex agent harness contract.

Acceptance criteria

• The Codex plugin declares that it owns the codex agent harness contract.
• Gateway startup includes required agent-harness owner plugins when config requires that runtime.
• Forced runtime config such as embeddedHarness.runtime = "codex" activates the Codex harness plugin even if no provider model scan catches it.
• Plugin diagnostics do not get treated as proof that the runtime harness has been activated.
• Tests cover model-reference-based and forced-runtime-based activation.

Suggested test coverage

• Startup plugin selection includes the Codex plugin for codex/gpt-5.4.
• Startup plugin selection includes the Codex plugin for embeddedHarness.runtime = "codex".
• A strict Codex-only config with fallback disabled does not fail because the harness is unregistered.

Related

• Parent: [Bug]: Track Codex harness stability work #66251
• Related model catalog issue: [Bug]: Native codex/* provider catalog not registered during gateway startup — Unknown model: codex/gpt-5.4 on every restart #64938
• Related startup/app-server contract drift: Codex app-server rejects stale serviceTier "priority", and startup warmup misses async model resolution #64815

Impact and severity

Affected: Users running OpenClaw with the bundled Codex harness.

Severity: High for Codex-only gateway startup when fallback is disabled.

Frequency: Observed during Codex harness stabilization investigation.

Consequence: Codex-backed gateway sessions can fail to start through the expected native harness even though configuration points at Codex.

Additional information

The local investigation has in-progress changes in this area. This issue is intended to capture the observed failure mode and the acceptance criteria for a focused fix.