OpenClaw's Codex Harness Reaches Full Plugin Hook Parity — Every Extension Point Now Works Natively

When OpenClaw shipped pluggable agent harnesses last month, the Codex extension was the first third-party runtime to go live. It worked — but with gaps. Plugin hooks that fired reliably in the core PI harness were silently skipped during native Codex turns. Prompt shims didn't apply. Compaction-aware automations ran blind. Lifecycle observers never triggered. As of this week, all of that is fixed. Three updates landed in a single day to close every remaining hook gap between the Codex harness and OpenClaw's core plugin system.

Prompt and Compaction Hooks Land First

The first update wires in the three shared hooks that control prompt assembly and context compaction: before_prompt_build, before_compaction, and after_compaction. These are the hooks that prompt shim plugins rely on to inject system instructions, modify context windows, or react to compaction events.

Until now, a plugin that registered a before_prompt_build hook would see it fire on standard PI turns but go silent on Codex app-server turns. That inconsistency forced plugin authors into harness-detection workarounds — checking which runtime was active and branching accordingly. With this update, the hooks fire identically regardless of which harness is executing the turn.

LLM Lifecycle Observers Close the Visibility Gap

The second update adds three lifecycle hooks: llm_input, llm_output, and agent_end. These are observability hooks — they let plugins inspect what goes into and comes out of the language model, and react when an agent turn completes.

The use cases are immediate. Logging plugins can capture full request/response pairs for audit trails. Cost-tracking extensions can meter token usage per turn. Safety plugins can inspect model outputs before they reach users. All of these patterns already worked on the PI harness. Now they work on Codex too.

The documentation update is precise: native Codex turns now respect before_prompt_build, before_compaction, after_compaction, llm_input, llm_output, and agent_end — the complete set. "Prompt shims, compaction-aware automation, and lifecycle observers can stay aligned with the PI harness," the updated reference states.

Tool-Result Middleware Completes the Picture

The third and final update tackles the most specialized extension point: tool-result middleware. Bundled plugins can now attach Codex app-server-specific tool_result middleware through a new API: api.registerCodexAppServerExtensionFactory(...).

This is the seam for async tool-result transforms — plugins that need to modify, enrich, or filter tool outputs before they're projected back into the OpenClaw transcript. Think of it as a post-processing layer that sits between the tool execution and the model's next turn. The plugin manifest must declare contracts.embeddedExtensionFactories: ["codex-app-server"] to opt in, keeping the surface area explicit.

What Parity Actually Means for Plugin Authors

Before this week, writing a plugin for OpenClaw meant writing it twice — once for the core harness, and once with fallbacks for Codex. Prompt shims had to detect the runtime. Lifecycle observers had to gracefully degrade. Tool-result transforms simply didn't work on Codex turns.

Now, the contract is simple: if your plugin uses the documented hook API, it works on both harnesses. No branching. No feature detection. No "works on PI but not on Codex" caveats in your README.

For the broader OpenClaw ecosystem, this is a maturity signal. Pluggable harnesses were announced as an architecture for extensibility. Parity makes them an architecture you can actually build on without worrying about which runtime your users happen to be running.

The Bigger Picture

OpenClaw's plugin SDK has been expanding rapidly in 2026 — task runtime APIs, swappable fetch backends, provider customization hooks, and now full harness parity. The trajectory is clear: the project is betting that its future depends less on what it ships in core and more on what third-party developers can build on top of it.

Codex hook parity removes one of the last barriers to that bet paying off. Plugin authors who were hesitant to invest in the SDK while harness support was inconsistent now have one less reason to wait.