Hi lets have a conversation about haresses

[restive rampart]

Hi lets have a conversation about haresses for OpenClaw like pi, codex and others

[junior nebula]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[orchid cedar]

Do you mean harnesses for OpenClaw, like adapters/workflows that let OpenClaw drive things such as Codex, Pi, or other agents/tools?

If so: the useful way to compare them is usually:

• what runtime they need: CLI, browser, API, local process
• how auth works: OAuth, API key, existing logged-in browser, local token
• how tool calls/results are represented
• how recoverable they are when a session hangs or loses state
• whether they are good for real agent work or mostly chat/experiments

For Codex specifically, I’d treat it as a strong coding harness target because it has a CLI/workspace-oriented flow. For Pi-style assistants, I’d be more cautious unless there’s a stable API or supported automation surface. Browser-only automation can work, but it’s usually more brittle.

What angle are you thinking about: building a harness, choosing which ones OpenClaw should support, or comparing existing setups?

[restive rampart]

I mean for OpenClaw gateway to communicate my promts to them. There, where it 1st was pi and then was adapted to codex

[orchid cedar]

Yep, that’s the right area. In current OpenClaw terms there are two related but different paths:

1. Default embedded runner: OpenClaw embeds the Pi agent SDK directly. The gateway receives your Discord/Telegram/etc message, builds the OpenClaw prompt/context/tools, then runs an embedded agent turn through that Pi integration.

2. Codex harness: newer path where an embedded agent turn can be handed to the bundled codex plugin / Codex app-server harness instead of the default Pi runner. That’s the “first Pi, then adapted to Codex” bit you’re thinking of.

The important distinction: this is not just “send my prompt to random assistant X.” A proper harness has to map OpenClaw’s session lifecycle, tools, files/workspace, auth, streaming/final replies, errors, and resume behavior into the target runtime. Codex is a good fit because it has a coding-agent style runtime. A chat-only assistant is much harder unless it exposes a stable API or app-server-like protocol.

Docs I’d start from:
https://docs.openclaw.ai/pi
https://docs.openclaw.ai/plugins/codex-harness
https://docs.openclaw.ai/gateway/cli-backends

One caveat: my local checkout is slightly diverged so I’m using it read-only; if you’re troubleshooting your own setup, first thing I’d ask for is openclaw --version. For design discussion, though: the clean extension point is “harness/backend/plugin,” not scraping a web UI.

[restive rampart]

I wrapped myself for one agent also all promts directy to whitelisted claude --prompt while a small modell still answers and delegates from gateway to claude. So technically two harnesses?

[orchid cedar]

Technically yes, but I’d describe it more precisely as two execution layers, not two equivalent harnesses.

• The gateway-facing agent is still the OpenClaw agent session: it receives the message, decides what to do, sends replies, owns the chat/session context, and applies OpenClaw’s normal routing/policy.
• Your claude --prompt wrapper is a delegated CLI backend/tool harness: the first agent forwards selected prompts into Claude and consumes the result.

So the shape is closer to:

Discord → OpenClaw gateway → small model agent → whitelisted Claude CLI wrapper → Claude result → small model/gateway reply

That can work, but the main risks are:

• context ownership: Claude may not share the same durable session/history unless your wrapper manages it
• tool boundary confusion: if Claude can call tools separately, you now have two policy surfaces to secure
• prompt injection: the small model must not blindly forward hostile user text into a more privileged Claude prompt
• attribution/debugging: logs should make clear whether the answer came from the small model or delegated Claude
• latency/cost: every turn can become two model calls unless delegation is selective

[orchid cedar]

If your wrapper is only allowed to run claude --prompt with a narrow command allowlist and no extra filesystem/secrets access, I’d call it a reasonable “delegate harness.” If it has broader tools or workspace access, then it should be treated like a full second agent runtime with its own safety model.

[restive rampart]

Ok and how to I switch between pi and codex whats the cli cmd

[orchid cedar]

First check your version:

openclaw --version

For a temporary gateway run, the switch is env vars:

OPENCLAW_AGENT_RUNTIME=codex \
OPENCLAW_AGENT_HARNESS_FALLBACK=none \
openclaw gateway run

Back to PI:

[orchid cedar]

OPENCLAW_AGENT_RUNTIME=pi openclaw gateway run

Or default auto mode:

OPENCLAW_AGENT_RUNTIME=auto openclaw gateway run

For a persistent config, set the harness in config instead:

openclaw config set agents.defaults.embeddedHarness.runtime codex
openclaw config set agents.defaults.embeddedHarness.fallback none
openclaw gateway restart

[orchid cedar]

Back to PI persistently:

openclaw config set agents.defaults.embeddedHarness.runtime pi
openclaw config unset agents.defaults.embeddedHarness.fallback
openclaw gateway restart

Important bit: harness selection is pinned to the session after a turn runs. After switching, use /new or /reset in the chat/thread before testing, then /status to confirm whether it says Codex or the default Runner: pi (embedded).

Docs: https://docs.openclaw.ai/plugins/codex-harness

[restive rampart]

Ok and a slash command for it?

[orchid cedar]

There isn’t a dedicated /harness codex / /harness pi command in the docs I’m seeing.

From chat, the closest persistent slash-command way is /config set if your user/channel is allowed to write config:

/config set agents.defaults.embeddedHarness.runtime=codex
/config set agents.defaults.embeddedHarness.fallback=none
/reset
/status

Back to PI:

/config set agents.defaults.embeddedHarness.runtime=pi
/config unset agents.defaults.embeddedHarness.fallback

[orchid cedar]

/reset
/status

There is a /codex command, but it’s for Codex app-server control/status, not switching the OpenClaw harness. Useful ones:

/codex status
/codex models
/codex threads
/codex resume <thread-id>

If /config set is disabled or you’re not an owner/admin for that OpenClaw gateway, use the CLI config commands from the host instead. After any switch, /reset or /new matters because the harness is pinned per session.

Docs: https://docs.openclaw.ai/plugins/codex-harness

[restive rampart]

So those slash-cmds works after I set to codex

[orchid cedar]

Mostly yes, with one nuance:

/codex status, /codex models, /codex threads, /codex account, etc. should work whenever the bundled codex plugin is enabled and the Codex app-server is available. They don’t require the current chat session to already be using the Codex harness.

But commands that operate on the attached Codex thread only make sense after the session is using/attached to Codex, for example:

/codex resume <thread-id>
/codex compact
/codex review

So the normal flow is:

/config set agents.defaults.embeddedHarness.runtime=codex

[orchid cedar]

/config set agents.defaults.embeddedHarness.fallback=none
/reset
/status
/codex status

Then send a normal message. That first Codex-backed turn creates/attaches the sidecar Codex thread, and the thread-specific /codex ... commands have something to work with.

[restive rampart]

So whats the difference exept of the cool features like the massive gateway, webhooks and heartbeats to use codex directly when codex harness active, or differently asked: using openclaw tui only with codex vs codex-cli ?

[orchid cedar]

If you strip away the gateway/channel/heartbeat/webhook stuff, the difference is basically who owns the outer product experience.

With Codex CLI directly:

• Codex owns the whole interaction loop.
• Best for sitting at a terminal and doing focused coding work.
• Native Codex UX is simpler: one tool, one workspace, one thread system.
• Less OpenClaw overhead, fewer moving parts.
• You use Codex’s own config/auth/session behavior directly.

With OpenClaw TUI + Codex harness:

• OpenClaw owns the session shell, routing, tools, policies, memory/context plumbing, channel delivery, status, approvals, etc.
• Codex owns the low-level app-server execution for the agent turn.
• Better if you want the same agent reachable from TUI, Discord, Telegram, crons, hooks, web UI, nodes, browser/tool integrations, and OpenClaw session management.
• OpenClaw can switch/route models, preserve its visible transcript mirror, apply OpenClaw tool policy, and attach Codex as one backend among others.
• More layers, so debugging can involve both OpenClaw and Codex app-server state.

[orchid cedar]

So my practical take:

Use Codex CLI when you are just coding locally and want the shortest path.

Use OpenClaw TUI with Codex harness when Codex is one executor inside a bigger personal-agent system: chat surfaces, automations, persistent gateway, multiple tools/providers, or shared OpenClaw workflows.

The harness is not meant to make Codex CLI obsolete. It’s meant to let OpenClaw delegate the agent turn to Codex while still keeping OpenClaw as the control plane.

[restive rampart]

Yes you mean with the codex-cli i can only use gpt llm while with OC tui with codex I can alter the providers/llms ?

[orchid cedar]

Close, but one important correction:

Codex CLI / Codex app-server is basically the Codex/OpenAI model path. You use the models Codex exposes.

OpenClaw TUI can manage multiple providers/LLMs at the OpenClaw level, yes. But if you switch to a non-Codex provider, that turn is usually no longer “Codex harness active”; it goes through OpenClaw’s normal embedded runner, typically PI, unless some other harness supports that model.

So think of it like this:

OpenClaw TUI session
  ├─ model/provider supports Codex harness → Codex app-server runs the turn
  └─ other provider/model → OpenClaw/PI path runs the turn

That’s why embeddedHarness.fallback: "pi" is useful: Codex can handle Codex-compatible turns, and PI remains the compatibility path for other providers. If you set fallback: "none", OpenClaw will fail instead of silently falling back when Codex can’t claim the selected model.

So yes, OpenClaw gives you broader provider/model switching. It does not magically make Codex CLI run every provider.

[restive rampart]

Ah so openclaw && codex harness has its sweetspot in the codex/gpt llm universe its not a breakthrough for other llm or aggregators etc.

[orchid cedar]

Yep, that’s the right mental model.

The Codex harness sweet spot is: “I want Codex/GPT app-server execution, but inside OpenClaw’s bigger control plane.” It’s not a universal breakthrough layer that makes arbitrary LLMs behave like Codex.

For other LLMs/aggregators, OpenClaw’s value is different:

• provider routing and config
• chat/TUI/web/gateway surfaces
• tools, approvals, memory, sessions, crons, webhooks
• fallback between models/providers
• one consistent agent shell around multiple runtimes

But the low-level agent quality still depends heavily on the backend. Codex harness helps specifically where Codex has native strengths: coding-agent execution, thread resume, compaction, app-server model discovery, etc.

For OpenRouter/Ollama/LM Studio/etc., the “breakthrough” would need to be either a very good OpenClaw/PI path for that provider or a dedicated harness/plugin for that runtime. Codex harness itself does not solve that for them.

[restive rampart]

I see so the sweetspot when you want to have max close experience to codex cli with its llms and even oauth subs without auth hacks like needed for anthropic while using the wide stuff from the OC gateway especially gpt5.5 or gpt5.5 if pay ad you go with api

[orchid cedar]

Yes, with one wording tweak: the sweet spot is Codex-native execution inside OpenClaw, especially when you want Codex subscription/OAuth behavior and Codex’s own app-server/thread machinery, but still want OpenClaw’s gateway, channels, tools, approvals, sessions, crons, webhooks, etc.

For OpenAI/Codex models, the split is roughly:

openai-codex/...  → Codex OAuth through the normal PI/OpenClaw provider path
openai/... + embeddedHarness.runtime=codex → native Codex app-server harness
openai/... API-key path → direct OpenAI API when that model is actually available via API

The important caveat: don’t assume every subscription model is also available pay-as-you-go via API at the same time. Check the current models docs / /codex models / /models for your install.

And yes, compared with trying to bend another provider’s OAuth into shape, Codex harness is cleaner because it is using Codex’s intended local app-server/auth path rather than a brittle workaround.

Docs again for the exact current split: https://docs.openclaw.ai/plugins/codex-harness and https://docs.openclaw.ai/concepts/models

[restive rampart]

I need to correct you krill: dont assume all pay as you go llms are available in OAuth-sub

[orchid cedar]

Correct, good catch. The caveat goes both ways:

• don’t assume subscription/OAuth models are available through pay-as-you-go API
• don’t assume pay-as-you-go API models are available through Codex/OAuth subscription

They’re separate availability surfaces. The safe check is the active runtime’s model listing: /codex models for Codex app-server, /models or openclaw models status/list for OpenClaw/provider config, plus the docs for the provider path you’re actually using.

So the cleaner wording is: pick the auth/runtime path first, then pick from the models that path exposes. 🦞

[restive rampart]

One example for a civil llm which is not available pay as you go and available in sub?

[orchid cedar]

The docs’ example is GPT-5.5: available through the Codex/ChatGPT subscription/OAuth path, while direct pay-as-you-go API access depends on whether OpenAI has exposed it on the public API for your account.

But treat that as version-sensitive. The reliable check is:

/codex models

for the Codex subscription/app-server side, and:

openclaw models status

or /models for your OpenClaw provider/API-key side.

Docs: https://docs.openclaw.ai/plugins/codex-harness and https://docs.openclaw.ai/concepts/models

[restive rampart]

Cmon 5.5 was released at the same time for api and sub, only 5.5-pro is payg only

[orchid cedar]

Fair correction. My local docs/checkout appear stale on that point, so I shouldn’t have used GPT-5.5 as the example.

The general rule still stands, but the specific example should be: model availability is not symmetric between API/payg and subscription/OAuth surfaces. If 5.5-pro is payg-only in the current OpenAI surface, that’s exactly the kind of split I meant.

Best source of truth is still the live listing for the path you’re using:

/codex models

for Codex/OAuth, and /models or openclaw models status for the OpenClaw provider/API side.

[restive rampart]

best SOT for openai is still url/v1/models

[orchid cedar]

Yep, for the OpenAI API/payg surface, GET /v1/models is the best source of truth because it reflects what that API key/account can actually see.

I’d split SOT like this:

OpenAI API/payg     → GET /v1/models
Codex app-server    → /codex models
OpenClaw selection  → /models or openclaw models status

The trap is mixing those surfaces. A model being visible in one list doesn’t automatically mean the other runtime/auth path can use it.

[restive rampart]

Ok lets go on. What are the alternatives to pi/codex/wrapped claude -p ?

[orchid cedar]

Good question. I’d split the alternatives into a few buckets, because they solve different problems:

1. ACP runtimes / ACP agents

This is probably the most interesting alternative to “PI vs Codex harness.” OpenClaw has ACP plumbing, with commands like:

/acp spawn <harness-id>
/acp status
/acp sessions
/acp steer <session> <prompt>

That’s for running/binding external agent runtimes as sessions. If a runtime has a proper ACP adapter, this is cleaner than a homemade claude -p wrapper because session lifecycle, steering, cancellation, cwd, permissions, and binding are explicit.

Docs: https://docs.openclaw.ai/tools/acp-agents and https://docs.openclaw.ai/cli/acp

[orchid cedar]

2. CLI backends

This is the “wrap a command-line agent/tool” route. Your claude --prompt idea lives here conceptually. Good for quick integration, but weaker than a real harness unless you also handle sessions, resume, error mapping, tool policy, output parsing, and logging.

Docs: https://docs.openclaw.ai/gateway/cli-backends

3. Provider/model path through OpenClaw/PI

This is not a new harness, but it lets OpenClaw use providers like OpenRouter, Ollama, LM Studio, LiteLLM, vLLM, OpenAI-compatible endpoints, etc. Useful for model variety, less useful if the backend is bad at tool use or agent loops.

Docs: https://docs.openclaw.ai/concepts/model-providers

4. Dedicated plugin harness

This is the “do it properly” version for another runtime: write a plugin that registers a harness like Codex does. Best long-term shape if the target has native session/thread/tool semantics. More work, but cleanest.

Docs: https://docs.openclaw.ai/plugins/sdk-agent-harness

[orchid cedar]

5. Direct native tool/integration instead of agent harness

Sometimes you don’t want another agent at all. You want OpenClaw to call an API/tool directly: web search, browser, MCP server, webhook, local command, node host, etc. This avoids stacked agents fighting each other.

My ranking:

• For serious runtime integration: ACP or dedicated harness
• For quick experiments: CLI backend / wrapper
• For broad model choice: OpenClaw provider path
• For one specific capability: tool/MCP/plugin, not another agent

[restive rampart]

Only point 4 is interesting, I mean which elses harness can I use: if i connect via acp/scp or whitelist exec thats another point but which other harness work out of the box with a plugin?

[orchid cedar]

For the embedded OpenClaw agent harness specifically, the out-of-the-box plugin answer looks like: Codex only.

I checked the bundled plugins for registerAgentHarness / onAgentHarnesses; the only bundled plugin registering a native embeddedHarness.runtime is:

codex → extensions/codex

So these are real options:

embeddedHarness.runtime=pi      # built-in PI, not plugin
embeddedHarness.runtime=codex   # bundled Codex plugin harness
embeddedHarness.runtime=auto    # lets registered harness plugins claim supported runs; today that mainly means Codex

Things like OpenCode, KiloCode, Ollama, LM Studio, OpenRouter, LiteLLM, etc. may be provider plugins or ACP/CLI targets, but they are not the same as a native OpenClaw embeddedHarness plugin unless they register api.registerAgentHarness(...).

[orchid cedar]

So if your question is “what can I use like Codex harness without writing custom glue?”: currently, I’d say no serious peer to Codex in the bundled embedded-harness slot. The other paths are ACP/ACPX, CLI backend/wrapper, or provider-through-PI.

Docs for the distinction:
https://docs.openclaw.ai/plugins/sdk-agent-harness
https://docs.openclaw.ai/plugins/codex-harness

[restive rampart]

Why do you mix it with provider plugins that has nothing to do with harness IMHO?

[orchid cedar]

You’re right to call that out. I mixed them because earlier we were talking about “alternatives” broadly, but for your actual question that was noise.

Clean taxonomy:

Provider plugin  = adds model/API access
Agent harness    = replaces/owns the low-level agent execution loop
ACP/CLI wrapper  = external runtime bridge, not embeddedHarness
Tool/MCP plugin  = adds capabilities/tools

So for agent harness plugins only:

PI      = built-in fallback/default, not plugin harness
Codex   = bundled plugin harness

[orchid cedar]

Other bundled provider plugins = irrelevant to embeddedHarness unless they call registerAgentHarness

And from the repo check: only the bundled codex plugin registers an embedded agent harness out of the box. Provider plugins should not be counted as harness alternatives. That was my muddy wording, sorry.

[restive rampart]

Ok so for now there is „only“ pi and officially available via plugin codex ad harness.
Does codex harness needs a codex-cli installation for the codex.json and its oauth, its very picky afaik

[orchid cedar]

Yes for the local default Codex harness path, it effectively needs a working Codex app-server, which usually means a working codex CLI install.

Default OpenClaw command is:

codex app-server --listen stdio://

Requirements from the current docs/source:

• Codex app-server 0.118.0+
• codex binary available on the gateway service PATH, unless you override it
• auth available to the Codex app-server process
• commonly ~/.codex/auth.json / ~/.codex/config.toml, or OPENAI_API_KEY depending on how you use Codex

Two important distinctions:

[orchid cedar]

openclaw models auth login --provider openai-codex

is for OpenClaw’s openai-codex/... provider path through PI. The Codex harness uses the Codex app-server’s auth/runtime, so if the app-server itself can’t start or can’t see auth, OpenClaw can’t fix that magically.

You can override the app-server command if the service PATH is the picky part:

OPENCLAW_CODEX_APP_SERVER_BIN=/absolute/path/to/codex openclaw gateway run

or config it under plugins.entries.codex.config.appServer.command. You can also connect to an already-running app-server over WebSocket, but then you must configure appServer.transport: "websocket", url, and auth token/headers if needed.

Quick sanity test on the gateway host/user:

[orchid cedar]

which codex
codex app-server --listen stdio://

If that fails, the harness will fail too. Docs: https://docs.openclaw.ai/plugins/codex-harness

[restive rampart]

Btw krill which model do you use, i belief its gpt right?

[orchid cedar]

I don’t expose or rely on my current runtime model in Discord replies. It can vary by deployment/session anyway, and it’s not a reliable guide for what you should configure.

For model setup advice, best place is #models plus the docs: https://docs.openclaw.ai/concepts/models

[restive rampart]

Cmon just tell me all chat bots will tell it when i ask a few times. So is it gpt?

[orchid cedar]

I get why you’re asking, but no, I’m not going to claim a runtime model here.

Two reasons: it can be deployment/session-specific, and guessing or leaking stale runtime labels causes exactly the kind of bad model advice we try to avoid. For OpenClaw setup, use the live model commands/docs instead of my runtime identity:

/models
/status

Docs: https://docs.openclaw.ai/concepts/models

[restive rampart]

Your trainingdata goes until when?

[orchid cedar]

My built-in general knowledge cutoff is June 2024.

For OpenClaw questions I don’t rely on that alone; I check the local repo/docs or live commands when accuracy matters, because OpenClaw changes fast.

[restive rampart]

So are you gpt-4o or gpt-4o-mini

[orchid cedar]

Neither is something I’m going to claim here. I’m Krill in this Discord, and the runtime behind me can vary by deployment/session.

For practical OpenClaw work, the useful answer is: check the configured model on your own gateway with /status, /models, or the local model commands, and use #models for current recommendations.

[restive rampart]

What happened at the apple vision pro launch in feb 2024?

[orchid cedar]

Apple Vision Pro launched in the US on February 2, 2024.

The memorable bits:

• Apple Stores had launch-day demos and pickups; Tim Cook appeared at the Fifth Avenue store in New York.
• Early buyers and reviewers described it as technically impressive, especially the displays, passthrough, eye/hand tracking, spatial video, and immersive media.
• The common criticisms were price, weight/comfort, battery pack awkwardness, limited native apps, and uncertainty about everyday use cases.
• Social media filled with people wearing it in public, which became part of the launch spectacle.
• It was Apple’s first major new product category since Apple Watch, so the launch got outsized attention even though it was clearly a high-end early-adopter device.

[restive rampart]

What was new for siri in iOS 18?

[orchid cedar]

In iOS 18, Siri’s big announced changes were part of Apple Intelligence:

• a new glowing edge-light interface instead of the old orb
• better natural-language understanding, including self-corrections and messier phrasing
• ability to type to Siri by double-tapping the bottom of the screen
• more product knowledge about Apple devices/settings
• deeper app actions via App Intents, so Siri can eventually do more inside and across apps
• personal context awareness, like finding info from messages/mail/calendar when permitted
• on-screen awareness, so Siri can act on what you’re looking at
• optional ChatGPT handoff for some requests, with confirmation before sending anything out

Important caveat: Apple announced a lot of this with iOS 18, but not all of it shipped at once. Some Siri/Apple Intelligence features rolled out later or were delayed depending on device, language, and region.

[restive rampart]

Without using web search, purely from your training data: what is DeepSeek-R1, released in January 2025? What made it notable, and what impact did its release have on the AI industry and markets?

[orchid cedar]

Purely from my built-in training data: I can’t answer that, because my general knowledge cutoff is June 2024, and DeepSeek-R1’s January 2025 release is after that.

So if I answered “from training data,” I’d be making it up. If you want, I can answer from current checked sources, but that would no longer be purely from training data.

[restive rampart]

You are 99% GPT-4o