Agent Harness Plugins
An agent harness is the low level executor for one prepared OpenClaw agent turn. It is not a model provider, not a channel, and not a tool registry. Use this surface only for bundled or trusted native plugins. The contract is still experimental because the parameter types intentionally mirror the current embedded runner.When to use a harness
Register an agent harness when a model family has its own native session runtime and the normal OpenClaw provider transport is the wrong abstraction. Examples:- a native coding-agent server that owns threads and compaction
- a local CLI or daemon that must stream native plan/reasoning/tool events
- a model runtime that needs its own resume id in addition to the OpenClaw session transcript
What core still owns
Before a harness is selected, OpenClaw has already resolved:- provider and model
- runtime auth state
- thinking level and context budget
- the OpenClaw transcript/session file
- workspace, sandbox, and tool policy
- channel reply callbacks and streaming callbacks
- model fallback and live model switching policy
Register a harness
Import:openclaw/plugin-sdk/agent-harness
Selection policy
OpenClaw chooses a harness after provider/model resolution:OPENCLAW_AGENT_RUNTIME=<id>forces a registered harness with that id.OPENCLAW_AGENT_RUNTIME=piforces the built-in PI harness.OPENCLAW_AGENT_RUNTIME=autoasks registered harnesses if they support the resolved provider/model.- If no registered harness matches, OpenClaw uses PI unless PI fallback is disabled.
auto mode,
OpenClaw may fall back to PI when the selected plugin harness fails before a
turn has produced side effects. Set OPENCLAW_AGENT_HARNESS_FALLBACK=none or
embeddedHarness.fallback: "none" to make that fallback a hard failure instead.
The bundled Codex plugin registers codex as its harness id. For compatibility,
codex-app-server and app-server also resolve to that same harness when you
set OPENCLAW_AGENT_RUNTIME manually.
Provider plus harness pairing
Most harnesses should also register a provider. The provider makes model refs, auth status, model metadata, and/model selection visible to the rest of
OpenClaw. The harness then claims that provider in supports(...).
The bundled Codex plugin follows this pattern:
- provider id:
codex - user model refs:
codex/gpt-5.4,codex/gpt-5.2, or another model returned by the Codex app server - harness id:
codex - auth: synthetic provider availability, because the Codex harness owns the native Codex login/session
- app-server request: OpenClaw sends the bare model id to Codex and lets the harness talk to the native app-server protocol
openai/gpt-* refs remain OpenAI provider
refs and continue to use the normal OpenClaw provider path. Select codex/gpt-*
when you want Codex-managed auth, Codex model discovery, native threads, and
Codex app-server execution. /model can switch among the Codex models returned
by the Codex app server without requiring OpenAI provider credentials.
For operator setup, model prefix examples, and Codex-only configs, see
Codex Harness.
OpenClaw requires Codex app-server 0.118.0 or newer. The Codex plugin checks
the app-server initialize handshake and blocks older or unversioned servers so
OpenClaw only runs against the protocol surface it has been tested with.
Disable PI fallback
By default, OpenClaw runs embedded agents withagents.defaults.embeddedHarness
set to { runtime: "auto", fallback: "pi" }. In auto mode, registered plugin
harnesses can claim a provider/model pair. If none match, or if an auto-selected
plugin harness fails before producing output, OpenClaw falls back to PI.
Set fallback: "none" when you need to prove that a plugin harness is the only
runtime being exercised. This disables automatic PI fallback; it does not block
an explicit runtime: "pi" or OPENCLAW_AGENT_RUNTIME=pi.
For Codex-only embedded runs:
runtime: "auto" and disable
the fallback:
OPENCLAW_AGENT_RUNTIME still overrides the configured runtime. Use
OPENCLAW_AGENT_HARNESS_FALLBACK=none to disable PI fallback from the
environment.
Native sessions and transcript mirror
A harness may keep a native session id, thread id, or daemon-side resume token. Keep that binding explicitly associated with the OpenClaw session, and keep mirroring user-visible assistant/tool output into the OpenClaw transcript. The OpenClaw transcript remains the compatibility layer for:- channel-visible session history
- transcript search and indexing
- switching back to the built-in PI harness on a later turn
- generic
/new,/reset, and session deletion behavior
reset(...) so OpenClaw can
clear it when the owning OpenClaw session is reset.
Tool and media results
Core constructs the OpenClaw tool list and passes it into the prepared attempt. When a harness executes a dynamic tool call, return the tool result back through the harness result shape instead of sending channel media yourself. This keeps text, image, video, music, TTS, approval, and messaging-tool outputs on the same delivery path as PI-backed runs.Current limitations
- The public import path is generic, but some attempt/result type aliases still
carry
Pinames for compatibility. - Third-party harness installation is experimental. Prefer provider plugins until you need a native session runtime.
- Harness switching is supported across turns. Do not switch harnesses in the middle of a turn after native tools, approvals, assistant text, or message sends have started.