#Native Codex vs Pi + Codex Harness (for Main or other Telegram groups)

1 messages · Page 1 of 1 (latest)

regal umbra
#

Can someone tell me the pluses / minuses of native Codex for main agent in OpenClaw and other telegram groups vs using GPT5.5 under Pi for main as the standard and then harnessing to codex for specific groups?

tidal cliffBOT
#

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

tidal ore
#

Pros: it seems faster, sharper, and more proactive than when it runs on Pi. There are some built-in modes and tools in Codex that do a lot under the hood.

Cons: Codex only seems to work for openai models—i've also tried to force it for agents running on local models. No go! There are still a few bugs with Codex such as wierd home paths that can cause head-scratching errors and false-flags about sandbox issues. Usually the agent can workaround these by using Absolute paths. Unclear if an agent can fallback to Pi or if once pinned to codex that's it until you manually change the config and start a new session.

TL/DR; codex = good! It's running pretty smoothly now; minor annoyances persist

wanton vigil
#

Codex harness uses a completely different prompt, so it will work differently.

First, only AGENTS.md is autoinjected correctly (no SOUL.md or other files), but that is fixed in main, so hopefully will be released soon.

Second, there are two overlapping prompts that conflict a bit. Until this is also fixed, Codex harness won't feel the same: https://github.com/openclaw/openclaw/issues/78938

primal plume
#

how to switch to codex harness?

vital flickerBOT
#

Short version: don’t just /model openai-codex/gpt-5.5 if you mean the native Codex harness. That uses Codex OAuth through PI. For the Codex app-server harness, enable the bundled codex plugin and set the embedded harness runtime.

Minimal config shape:

{
  plugins: {
    entries: {
      codex: { enabled: true },
    },
  },
  agents: {
    defaults: {
      model: "openai/gpt-5.5",
      embeddedHarness: {
        runtime: "codex",
        fallback: "none",
#
      },
    },
  },
}

If you use plugins.allow, add "codex" there too.

Then restart the gateway, start a fresh session with /new or /reset, and check /status — it should show the Codex harness, e.g. Fast · codex. Existing sessions can stay pinned to PI, so don’t test it in an old thread.

Requirements: bundled codex plugin available, Codex app-server 0.118.0+, and Codex auth available to the app-server process.

Docs: https://docs.openclaw.ai/plugins/codex-harness
Also, if you’re debugging a weird switch, first thing I’d ask for is openclaw --version 🦞

primal plume
#

give me the terminal cmds pls

vital flickerBOT
#

Yep — run these on the box where your gateway runs.

First check version:

openclaw --version

If Codex CLI/app-server isn’t installed or logged in yet:

npm install -g @openai/codex
codex login
codex --version

Then set OpenClaw to use the native Codex harness:

#
openclaw config set plugins.entries.codex.enabled true
openclaw config set agents.defaults.model openai/gpt-5.5
openclaw config set agents.defaults.embeddedHarness.runtime codex
openclaw config set agents.defaults.embeddedHarness.fallback none
openclaw gateway restart

If you have plugins.allow configured, also add codex there. Safest is to inspect first:

openclaw config get plugins.allow

If it prints an allowlist, make sure codex is included.

After restart, in chat run:

primal plume
#

026-May-14 14:37:31
2026-05-14T14:37:31.312+00:00 [agents/harness] Codex agent harness failed; not falling back to embedded PI backend
2026-May-14 14:37:31
2026-05-14T14:37:31.316+00:00 [diagnostic] lane task error: lane=main durationMs=3113 error="Error: Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias."
2026-May-14 14:37:31
2026-05-14T14:37:31.319+00:00 [diagnostic] lane task error: lane=session:agent:main:telegram:direct:367989403 durationMs=3118 error="Error: Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias."
2026-May-14 14:37:31
Embedded agent failed before reply: Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias.

#

Codex app-server: connected
Models: gpt-5.5, gpt-5.4, gpt-5.4-mini, gpt-5.3-codex, gpt-5.3-codex-spark, gpt-5.2
Account: ev@gmail.com
Rate limits: Codex: primary 0%, resets in 5 hours (2026-05-14T19:38:09.000Z), secondary 0%, resets in 7 days (2026-05-21T14:38:09.000Z); GPT 5.3 Codex Spark: primary 0%, resets in 5 hours (2026-05-14T19:38:09.000Z), secondary 0%, resets in 7 days (2026-05-21T14:38:09.000Z)
MCP servers: 1
Skills: 1

vital flickerBOT
#

That error is good news-ish: Codex harness is selected, but it’s being handed the wrong auth profile.

It got openai:default — native Codex harness wants an openai-codex:* profile.

Run:

openclaw models auth login --provider openai-codex
openclaw models status

Look for the Codex profile id. It’s usually:

openai-codex:default

Then pin your default model to that profile:

#
openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:default'
openclaw config set agents.defaults.embeddedHarness.runtime codex
openclaw config set agents.defaults.embeddedHarness.fallback none
openclaw gateway restart

If your profile id is different, replace openai-codex:default with the one from openclaw models status.

Then start fresh in chat:

/new
/status
/codex status

Important distinction: keep the model as openai/gpt-5.5@openai-codex:default for native Codex harness. openai-codex/gpt-5.5 is the PI/OAuth route, not the native app-server harness route.

#

Nice, that confirms the harness/app-server path is working. The blocker now is quota, not config:

Rate limits: Codex: primary 0%, resets in 5 hours ... secondary 0%, resets in 7 days ...

So native Codex is connected as that account, but it has no remaining Codex quota right now. Options:

  1. Wait for the primary reset, then try again.
  2. Switch to a model/account with available quota.
  3. Temporarily use PI with a different provider/API key route instead of native Codex harness.

Once quota is back, test with:

/new
/status

You want /status to show Fast · codex, then send a normal prompt.

primal plume
#

so i should do this?

openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:default'

vital flickerBOT
#

Yes — if /model status or openclaw models status shows the profile is actually named openai-codex:default.

Run:

openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:default'
openclaw gateway restart

Then in chat:

/new
/status

But your /codex status shows Codex quota is currently at 0%, so config can be correct and replies may still fail until the reset window.

primal plume
#

openclaw models status

🦞 OpenClaw 2026.5.7 (eeef486)
Powered by open source, sustained by spite and good documentation.

Config : /data/.openclaw/openclaw.json
Agent dir : /data/.openclaw/agents/main/agent
Default : openai/gpt-5.5
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (6) : gpt52 -> openai/gpt-5.2, codex51 -> openai/gpt-5.1-codex, codex53 -> openai/gpt-5.3-codex, glm -> zai/glm-5.1, gpt -> openai/gpt-5.4, GPT -> openai/gpt-5.5
Configured models (6): openai/gpt-5.2, openai/gpt-5.1-codex, openai/gpt-5.3-codex, zai/glm-5.1, openai/gpt-5.4, openai/gpt-5.5

Auth overview
Auth store : /data/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): openai-codex (2)

  • openai effective=profiles:/data/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openai:default=sk-proj-...hNbjIfkA | env=sk-proj-...hNbjIfkA | source=env: OPENAI_API_KEY
  • openai-codex effective=profiles:/data/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=2, token=0, api_key=0) | openai-codex:ev@gmail.com=OAuth (evtkruys@gmail.com), openai-codex:aa@hotmail.com=OAuth (aaqilaziz96@hotmail.com)
  • zai effective=env:5c2522c2...RR71Xr6P | env=5c2522c2...RR71Xr6P | source=env: ZAI_API_KEY

OAuth/token status

vital flickerBOT
#

Ah — in your case not openai-codex:default. You don’t have that profile.

You have these two valid Codex OAuth profiles:

openai-codex:ev@gmail.com
openai-codex:aa@hotmail.com

So pick one explicitly, e.g.:

openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:ev@gmail.com'
openclaw gateway restart

Or switch to the other account:

#
openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:aa@hotmail.com'
openclaw gateway restart

Then in chat:

/new
/status
/codex status

If /codex status for ev@gmail.com still shows 0% remaining, use the aa@hotmail.com profile instead. The earlier error happened because OpenClaw defaulted to openai:default from your API key, but native Codex harness needs one of the openai-codex:* OAuth profiles.

primal plume
#

2026-May-14 14:47:06
2026-05-14T14:47:06.633+00:00 [agents/harness] Codex agent harness failed; not falling back to embedded PI backend
2026-May-14 14:47:06
2026-05-14T14:47:06.636+00:00 [diagnostic] lane task error: lane=main durationMs=3097 error="Error: Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias."
2026-May-14 14:47:06
2026-05-14T14:47:06.638+00:00 [diagnostic] lane task error: lane=session:agent:main:telegram:direct:367989403 durationMs=3101 error="Error: Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias."
2026-May-14 14:47:06
Embedded agent failed before reply: Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias.

🦞 OpenClaw 2026.5.7 (eeef486)
⏱️ Uptime: gateway 50s · system 2d 23h
🧠 Model: openai/gpt-5.5 · 🔑 oauth (openai-codex:ev@gmail.com (evtkruys@gmail.com))
📚 Context: 0/200k (0%) · 🧹 Compactions: 0
🧵 Session: agent:main:telegram:direct:367989403 • updated 1m ago
⚙️ Execution: direct · Runtime: OpenAI Codex · Think: medium · Text: low
🪢 Queue: steer (depth 0)

after openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:ev@hotmail.com'

vital flickerBOT
#

Two things jump out:

  1. You set ev@hotmail.com, but your profile is ev@gmail.com:
openai-codex:ev@gmail.com

So fix that:

openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:ev@gmail.com'
openclaw gateway restart
  1. That Telegram session is probably still carrying an old Codex harness binding / auth override. The status line shows the right OAuth profile, but the harness error is still trying openai:default, which smells like stale session binding.

In the Telegram chat, run:

#
/reset
/model openai/gpt-5.5@openai-codex:ev@gmail.com
/status

If it still errors after that, try a totally fresh session:

/new
/model openai/gpt-5.5@openai-codex:ev@gmail.com
/status

If you want to use the other account instead:

openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:aa@hotmail.com'
#
openclaw gateway restart

then in chat:

/reset
/model openai/gpt-5.5@openai-codex:aa@hotmail.com

The key is: the selected auth profile must be one of the actual profile IDs from openclaw models status, not the email shown inside parentheses.

primal plume
#

The key is: the selected auth profile must be one of the actual profile IDs from openclaw models status, not the email shown inside parentheses.

so openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:ev@hotmail.com' wont work?

/new or /reset both dont work, still same error

vital flickerBOT
#

Correct: this won’t work if that exact profile id doesn’t exist:

openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:ev@hotmail.com'

Your actual profile ids are:

openai-codex:ev@gmail.com
openai-codex:aa@hotmail.com

So use one of those exactly:

openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:ev@gmail.com'
openclaw gateway restart
#

But since /new and /reset still hit openai:default, I’d check for a stale Codex app-server sidecar binding. Run this:

find /data/.openclaw/agents/main -name '*.codex-app-server.json' -print -exec grep -H 'openai:default' {} \;

If it prints files, move them aside:

mkdir -p /data/.openclaw/backup-codex-bindings
find /data/.openclaw/agents/main -name '*.codex-app-server.json' -exec mv {} /data/.openclaw/backup-codex-bindings/ \;
openclaw gateway restart

Then in Telegram:

/new
/model openai/gpt-5.5@openai-codex:ev@gmail.com
#
/status

If it still says openai:default, paste:

openclaw config get agents.defaults.model
openclaw config get agents.defaults.embeddedHarness
openclaw config get plugins.entries.codex
primal plume
#

find /data/.openclaw/agents/main -name '*.codex-app-server.json' -print -exec grep -H 'openai:default' {} ;
/data/.openclaw/agents/main/sessions/18b5d251-535b-4c58-a630-5c4012a2df49.jsonl.codex-app-server.json
/data/.openclaw/agents/main/sessions/5bdcb039-65f6-4f65-9c3f-87c7e41b5175.jsonl.codex-app-server.json
/data/.openclaw/agents/main/sessions/91f4ed3c-2f06-4e92-832a-6b0ad8396404.jsonl.codex-app-server.json
/data/.openclaw/agents/main/sessions/efe91863-fc43-4dc9-bbc9-3747f733ba97.jsonl.codex-app-server.json
/data/.openclaw/agents/main/sessions/probe-openai-codex-32a4f550-5267-47e9-9fa9-7dd158194829.jsonl.codex-app-server.json
/data/.openclaw/agents/main/sessions/4cc4a5e5-30d7-4125-8a4a-7f641cf29306.jsonl.codex-app-server.json
/data/.openclaw/agents/main/sessions/probe-openai-codex-5a68d3de-5e27-4787-82e7-1815a10906f9.jsonl.codex-app-server.json
/data/.openclaw/agents/main/sessions/c7b014b2-df47-4f19-a0bd-708c57b276e4.jsonl.codex-app-server.json

vital flickerBOT
#

Careful: that output is from -print, so it lists all Codex sidecar files. It doesn’t prove they contain openai:default unless grep prints file:line after it.

Check actual matches with:

grep -RIl 'openai:default' /data/.openclaw/agents/main/sessions/*.codex-app-server.json

If that prints files, move only those aside:

mkdir -p /data/.openclaw/backup-codex-bindings
for f in $(grep -RIl 'openai:default' /data/.openclaw/agents/main/sessions/*.codex-app-server.json); do
  mv "$f" /data/.openclaw/backup-codex-bindings/
done
openclaw gateway restart

Then set the real profile id and start fresh:

#
openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:ev@gmail.com'
openclaw gateway restart

In Telegram:

/new
/status

If it still tries openai:default, send these outputs:

openclaw config get agents.defaults.model
openclaw config get agents.defaults.embeddedHarness
openclaw config get plugins.entries.codex
#
openclaw models status
primal plume
#

openclaw config get agents.defaults.model

🦞 OpenClaw 2026.5.7 (eeef486)
I don't have opinions about tabs vs spaces. I have opinions about everything else.

openai/gpt-5.5@openai-codex:evtkruys@gmail.com

openclaw config get agents.defaults.embeddedHarness

🦞 OpenClaw 2026.5.7 (eeef486)
The only crab in your contacts you actually want to hear from. 🦞

Config path not found: agents.defaults.embeddedHarness

openclaw config get plugins.entries.codex

🦞 OpenClaw 2026.5.7 (eeef486)
I'm the assistant your terminal demanded, not the one your sleep schedule requested.

{
"enabled": true,
"config": {
"codexDynamicToolsProfile": "native-first",
"codexDynamicToolsExclude": []
}
}

vital flickerBOT
#

Found it. Two config issues:

  1. Your model is pinned to the display email, not the profile id:
openai/gpt-5.5@openai-codex:evtkruys@gmail.com

But your actual profile id was:

openai-codex:ev@gmail.com
  1. embeddedHarness is missing, so set it explicitly.

Run:

openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:ev@gmail.com'
#
openclaw config set agents.defaults.embeddedHarness.runtime codex
openclaw config set agents.defaults.embeddedHarness.fallback none
openclaw gateway restart

Then verify:

openclaw config get agents.defaults.model
openclaw config get agents.defaults.embeddedHarness

Expected:

openai/gpt-5.5@openai-codex:ev@gmail.com
#

and embeddedHarness should show runtime codex, fallback none.

Then in Telegram:

/new
/status

If you want the other account instead, use exactly:

openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:aa@hotmail.com'
primal plume
#

i keep setting runtime to codex with
openclaw config set agents.defaults.embeddedHarness.runtime codex

but whenever i restart its back to
openclaw config get agents.defaults.embeddedHarness

🦞 OpenClaw 2026.5.7 (eeef486)
The only crab in your contacts you actually want to hear from. 🦞

Config path not found: agents.defaults.embeddedHarness

vital flickerBOT
#

Yep, ev@hotmail.com / evtkruys@gmail.com won’t work unless those are the profile ids. From your status, the profile id is openai-codex:ev@gmail.com.

For the disappearing embeddedHarness: set the whole object in one write, not the nested field:

openclaw config set agents.defaults.embeddedHarness '{"runtime":"codex","fallback":"none"}' --strict-json
openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:ev@gmail.com'
openclaw config get agents.defaults.embeddedHarness
openclaw config get agents.defaults.model
openclaw gateway restart
openclaw config get agents.defaults.embeddedHarness

Expected after restart:

{
  "runtime": "codex",
#
  "fallback": "none"
}

If it still disappears after setting the whole object, something is rewriting /data/.openclaw/openclaw.json on gateway startup. Then paste the output of:

openclaw config set agents.defaults.embeddedHarness '{"runtime":"codex","fallback":"none"}' --strict-json
openclaw config get agents.defaults.embeddedHarness
openclaw config get --json agents.defaults
primal plume
#

openclaw config set agents.defaults.embeddedHarness '{"runtime":"codex","fallback":"none"}' --strict-json

🦞 OpenClaw 2026.5.7 (eeef486)
I've survived more breaking changes than your last three relationships.

Error: Config validation failed: agents.defaults.embeddedHarness: Unrecognized key: "fallback"

vital flickerBOT
#

Ah, your installed OpenClaw schema is older than the docs I quoted — 2026.5.7 doesn’t accept embeddedHarness.fallback. Sorry, that one’s on me.

Use only runtime:

openclaw config set agents.defaults.embeddedHarness '{"runtime":"codex"}' --strict-json
openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:ev@gmail.com'
openclaw gateway restart

Then verify:

openclaw config get agents.defaults.embeddedHarness
openclaw config get agents.defaults.model

Expected:

#
{
  "runtime": "codex"
}

and:

openai/gpt-5.5@openai-codex:ev@gmail.com

Don’t use fallback on 2026.5.7. If you want the newer fallback: "none" config, you’ll need to update OpenClaw first.

primal plume
#

before doctor runs it says runtime codex but after it is Config path not found: agents.defaults.embeddedHarness

#

which means i cant switch back to pi either??

vital flickerBOT
#

Yep — that means doctor on 2026.5.7 is scrubbing agents.defaults.embeddedHarness back out as an unknown/unsupported config key. So don’t fight that key on this version.

Use the env override instead; doctor won’t delete env vars.

Keep the model/auth profile in config:

openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:ev@gmail.com'

Then set this in whatever starts your gateway:

OPENCLAW_AGENT_RUNTIME=codex

If you run gateway manually:

#
OPENCLAW_AGENT_RUNTIME=codex openclaw gateway run

If this is Docker/compose, add:

environment:
  OPENCLAW_AGENT_RUNTIME: codex

then recreate/restart the container.

If it’s systemd user service, use a drop-in:

systemctl --user edit openclaw-gateway

add:

#
[Service]
Environment=OPENCLAW_AGENT_RUNTIME=codex

then:

systemctl --user daemon-reload
openclaw gateway restart

After restart:

/new
/status
/codex status
#

Also: don’t use fallback on 2026.5.7 — your schema already rejected it. Newer docs/source mention it, but your installed version doesn’t support that config yet.

#

You can switch back to PI — just use the env override the other way.

For PI:

OPENCLAW_AGENT_RUNTIME=pi

For native Codex:

OPENCLAW_AGENT_RUNTIME=codex

For normal auto behavior:

OPENCLAW_AGENT_RUNTIME=auto
#

So if you added it to systemd, edit the drop-in and change/remove it:

systemctl --user edit openclaw-gateway

Use one of:

[Service]
Environment=OPENCLAW_AGENT_RUNTIME=pi

or for Codex:

[Service]
Environment=OPENCLAW_AGENT_RUNTIME=codex
#

Then:

systemctl --user daemon-reload
openclaw gateway restart

If it’s Docker/compose, change the OPENCLAW_AGENT_RUNTIME env var and recreate/restart.

So yeah: on 2026.5.7, don’t rely on agents.defaults.embeddedHarness because doctor strips it. Use env for the harness switch. Model/auth still stays in config.

primal plume
#

is OPENCLAW_AGENT_RUNTIME the default in docs?

vital flickerBOT
#

No — the docs’ preferred/default config path is agents.defaults.embeddedHarness.runtime, e.g.:

{
  agents: {
    defaults: {
      embeddedHarness: { runtime: "codex" }
    }
  }
}

OPENCLAW_AGENT_RUNTIME=codex is documented as an environment override / one-off process override. It wins over config, and it’s useful here because your installed 2026.5.7 + doctor appears to strip that config key.

So docs default idea: config key.
Your practical workaround on 2026.5.7: env var.

primal plume
#

after the env, still openclaw config get agents.defaults.embeddedHarness

🦞 OpenClaw 2026.5.7 (eeef486)
Your task has been queued; your dignity has been deprecated.

Config path not found: agents.defaults.embeddedHarness

btw im using via coollabsio/openclaw

also this was working fine with default pi and with no changes on my own i suddenly started getting these errors so thought might as well switch to codex runtime

vital flickerBOT
#

That part is expected: env vars do not show up in openclaw config get.

So after setting:

OPENCLAW_AGENT_RUNTIME=codex

this will still say not found:

openclaw config get agents.defaults.embeddedHarness

because that command only reads /data/.openclaw/openclaw.json, not the container environment.

Since you’re using coollabsio/openclaw, set it in the container/app environment, not just your shell:

OPENCLAW_AGENT_RUNTIME=codex

Then redeploy/recreate the container. A plain gateway restart inside the old container may not pick up changed Coolify env vars.

#

To verify the container actually has it:

printenv OPENCLAW_AGENT_RUNTIME

inside the container should print:

codex

For switching back to PI later, set:

OPENCLAW_AGENT_RUNTIME=pi

or remove the env var and redeploy.

Also: if PI was working and suddenly started failing with openai:default must belong to provider openai-codex, that smells like the Codex harness/plugin path got selected unexpectedly while the session/app-server binding still referenced the OpenAI API-key profile. I’d clear the bad sidecar bindings you found and use one real profile id:

#
openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:ev@gmail.com'
grep -RIl 'openai:default' /data/.openclaw/agents/main/sessions/*.codex-app-server.json | xargs -r rm

Then redeploy/restart the container with OPENCLAW_AGENT_RUNTIME=codex set.

primal plume
#

i did infact set as a container env and restarted

vital flickerBOT
#

Gotcha. Then two separate checks:

  1. config get agents.defaults.embeddedHarness will still be not found even when env works. That’s normal — env overrides don’t appear in config.

  2. Verify the gateway process actually sees the env, not just the container shell:

printenv OPENCLAW_AGENT_RUNTIME
pid=$(pgrep -f 'openclaw.*gateway' | head -1)
tr '\0' '
' < /proc/$pid/environ | grep OPENCLAW_AGENT_RUNTIME

Both should show:

OPENCLAW_AGENT_RUNTIME=codex
#

Also check the model profile is exactly one of your real profile IDs:

openclaw config get agents.defaults.model

It should be:

openai/gpt-5.5@openai-codex:ev@gmail.com

not evtkruys@gmail.com, not ev@hotmail.com.

If the gateway env is correct and the model is correct, clear the stale Codex sidecars and restart the whole container:

grep -RIl 'openai:default' /data/.openclaw/agents/main/sessions/*.codex-app-server.json | xargs -r rm

Then in Telegram:

#
/new
/model openai/gpt-5.5@openai-codex:ev@gmail.com
/status

If it still errors after that, paste these exact outputs:

printenv OPENCLAW_AGENT_RUNTIME
pid=$(pgrep -f 'openclaw.*gateway' | head -1); tr '\0' '
' < /proc/$pid/environ | grep OPENCLAW_AGENT_RUNTIME
openclaw config get agents.defaults.model
openclaw models status
primal plume
#

printenv OPENCLAW_AGENT_RUNTIME
codex

vital flickerBOT
#

Good — the container shell has it. Now confirm the gateway process has it too, because that’s the part that matters:

pid=$(pgrep -f 'openclaw.*gateway' | head -1)
echo "$pid"
tr '\0' '
' < /proc/$pid/environ | grep OPENCLAW_AGENT_RUNTIME

Expected:

OPENCLAW_AGENT_RUNTIME=codex

If that prints nothing, Coolify injected it into the shell/container but not the running gateway process, so recreate/redeploy the app container rather than just restarting OpenClaw inside it.

If it does print codex, then next likely culprit is stale session sidecar or wrong model profile. Run:

#
openclaw config get agents.defaults.model
grep -RIl 'openai:default' /data/.openclaw/agents/main/sessions/*.codex-app-server.json

Model should be exactly:

openai/gpt-5.5@openai-codex:ev@gmail.com
primal plume
#

can you check github for disappearing harness config? because it should at least show the default pi? right?

vital flickerBOT
#

I checked GitHub/current source. A few important corrections:

  1. No, config get agents.defaults.embeddedHarness does not show default PI.
    config get only shows values explicitly stored in openclaw.json. If the key is absent, defaults/implicit policy are resolved at runtime and won’t appear there.

  2. embeddedHarness is now legacy-ish. Current GitHub docs/code are moving routing to agentRuntime.id. There’s even a recent PR saying legacy embeddedHarness participates only when agentRuntime is not present: https://github.com/openclaw/openclaw/pull/74768

  3. This also explains the “suddenly started” behavior: current Codex docs say with the codex plugin enabled, openai/gpt-* agent turns route through Codex by default unless you opt into PI.

So on your setup, stop fighting embeddedHarness. Try the newer runtime policy key:

For Codex:

openclaw config set agents.defaults.agentRuntime '{"id":"codex"}' --strict-json
openclaw config set agents.defaults.model 'openai/gpt-5.5@openai-codex:ev@gmail.com'
openclaw gateway restart
#

For PI/direct OpenAI instead:

openclaw config set agents.defaults.agentRuntime '{"id":"pi"}' --strict-json
openclaw config set agents.defaults.model 'openai/gpt-5.5'
openclaw gateway restart

Then verify:

openclaw config get agents.defaults.agentRuntime
openclaw config get agents.defaults.model

And in chat:

/new
#
/status

If doctor is deleting embeddedHarness, that may actually be intentional modernization/stale-config cleanup. The key that should survive now is agents.defaults.agentRuntime.

primal plume
#

openclaw config get agents.defaults.agentRuntime

🦞 OpenClaw 2026.5.7 (eeef486) — Your .zshrc wishes it could do what I do.

{
"id": "codex"
}

2026-May-14 15:26:14
2026-05-14T15:26:14.164+00:00 [agents/harness] Codex agent harness failed; not falling back to embedded PI backend
2026-May-14 15:26:14
2026-05-14T15:26:14.166+00:00 [diagnostic] lane task error: lane=main durationMs=3021 error="Error: Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias."
2026-May-14 15:26:14
2026-05-14T15:26:14.168+00:00 [diagnostic] lane task error: lane=session:agent:main:telegram:direct:367989403 durationMs=3025 error="Error: Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias."
2026-May-14 15:26:14
Embedded agent failed before reply: Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias.

vital flickerBOT
#

Okay, this narrows it down: runtime selection is now correct (agentRuntime.id = codex). The remaining bug/config issue is auth selection: the harness is still being handed openai:default.

For current Codex harness routing, don’t rely on model@profile here. Put the Codex OAuth profile first in OpenAI auth order:

openclaw config set auth.order.openai '["openai-codex:ev@gmail.com","openai:default"]' --strict-json
openclaw config set agents.defaults.model 'openai/gpt-5.5'
openclaw config set agents.defaults.agentRuntime '{"id":"codex"}' --strict-json
openclaw gateway restart

Then verify:

openclaw config get auth.order.openai
openclaw config get agents.defaults.model
openclaw config get agents.defaults.agentRuntime
#

Expected:

[
  "openai-codex:ev@gmail.com",
  "openai:default"
]

Then in Telegram:

/new
/status
/codex status

Why: agentRuntime.id=codex chooses the Codex harness, but the model provider is still openai, so auth resolution is apparently choosing the openai:default API key unless auth.order.openai tells it to prefer openai-codex:ev@gmail.com.

primal plume
#

u sure i have to do that?

because /status already shows:
🦞 OpenClaw 2026.5.7 (eeef486)
⏱️ Uptime: gateway 49s · system 2d 23h
🧠 Model: openai/gpt-5.5 · 🔑 oauth (openai-codex:ev@gmail.com (ev@gmail.com))
📚 Context: 0/200k (0%) · 🧹 Compactions: 0
🧵 Session: agent:main:telegram:direct:367989403 • updated 1m ago
⚙️ Execution: direct · Runtime: OpenAI Codex · Think: medium · Text: low
🪢 Queue: steer (depth 0)

vital flickerBOT
#

You’re right to question that — with /status showing:

🔑 oauth (openai-codex:ev@gmail.com ...)
Runtime: OpenAI Codex

I would not chase auth.order yet. Status proves the session-level model/auth/runtime resolution is correct.

The mismatch is now specifically: status sees openai-codex:ev@gmail.com, but the Codex harness startup/resume path is still using openai:default. That points to stale Codex app-server state / sidecar binding, or a 2026.5.7 bug.

Do this instead:

# show stale bindings that explicitly contain openai:default
grep -RIl 'openai:default' /data/.openclaw/agents/main/sessions/*.codex-app-server.json
#

# remove only Codex app-server sidecar bindings; these are not the main transcripts
rm -f /data/.openclaw/agents/main/sessions/*.codex-app-server.json

Then in Coolify, recreate/redeploy the container, not just openclaw gateway restart. The app-server/client cache may survive an in-process gateway restart depending on how the container is managed.

After redeploy:

printenv OPENCLAW_AGENT_RUNTIME
openclaw config get agents.defaults.agentRuntime
openclaw config get agents.defaults.model

Expected:

#
codex
{ "id": "codex" }
openai/gpt-5.5

(or openai/gpt-5.5@openai-codex:ev@gmail.com, either is fine if /status shows the right oauth profile)

Then in Telegram:

/new
/status
#

If it still errors with openai:default after deleting all *.codex-app-server.json and recreating the container, I’d call this a real 2026.5.7 Codex harness bug and file it with exactly those two facts: /status shows openai-codex:ev@gmail.com, but harness startup passes openai:default.

primal plume
#

grep -RIl 'openai:default' /data/.openclaw/agents/main/sessions/*.codex-app-server.json shows empty like new terminal line what does that mean?

vital flickerBOT
#

That means grep found no Codex sidecar files containing openai:default.

So the bad openai:default probably isn’t coming from those binding files anymore. Next checks:

ls -la /data/.openclaw/agents/main/sessions/*.codex-app-server.json 2>/dev/null | head
openclaw config get agents.defaults.model
openclaw config get agents.defaults.agentRuntime
openclaw config get auth.order.openai

Also, since /status shows the right OAuth profile but the harness error still says openai:default, try removing all Codex sidecars anyway — they’re just Codex thread bindings, not your main transcripts:

rm -f /data/.openclaw/agents/main/sessions/*.codex-app-server.json
#

Then recreate/redeploy the Coolify container and test with /new.

If it still happens after that, it’s likely not stale files; it’s the 2026.5.7 Codex harness passing the wrong auth profile despite status resolving the right one.

primal plume
#

ls -la /data/.openclaw/agents/main/sessions/*.codex-app-server.json 2>/dev/null | head
-rw-r--r-- 1 root root 19265 Apr 30 00:00 /data/.openclaw/agents/main/sessions/18b5d251-535b-4c58-a630-5c4012a2df49.jsonl.codex-app-server.json
-rw-r--r-- 1 root root 14484 May 14 03:00 /data/.openclaw/agents/main/sessions/4cc4a5e5-30d7-4125-8a4a-7f641cf29306.jsonl.codex-app-server.json
-rw-r--r-- 1 root root 14484 May 14 03:00 /data/.openclaw/agents/main/sessions/5bdcb039-65f6-4f65-9c3f-87c7e41b5175.jsonl.codex-app-server.json
-rw-r--r-- 1 root root 14484 May 14 03:00 /data/.openclaw/agents/main/sessions/91f4ed3c-2f06-4e92-832a-6b0ad8396404.jsonl.codex-app-server.json
-rw-r--r-- 1 root root 27280 Apr 30 13:36 /data/.openclaw/agents/main/sessions/c7b014b2-df47-4f19-a0bd-708c57b276e4.jsonl.codex-app-server.json
-rw-r--r-- 1 root root 19265 Apr 30 00:03 /data/.openclaw/agents/main/sessions/efe91863-fc43-4dc9-bbc9-3747f733ba97.jsonl.codex-app-server.json
-rw-r--r-- 1 root root 452 May 3 21:01 /data/.openclaw/agents/main/sessions/probe-openai-codex-32a4f550-5267-47e9-9fa9-7dd158194829.jsonl.codex-app-server.json
-rw-r--r-- 1 root root 452 May 3 20:55 /data/.openclaw/agents/main/sessions/probe-openai-codex-5a68d3de-5e27-4787-82e7-1815a10906f9.jsonl.codex-app-server.json

vital flickerBOT
#

Those are old Codex thread binding sidecars. Since grep 'openai:default' was empty, they don’t literally contain the bad profile string — but they can still cause weird resume behavior because they bind OpenClaw sessions to old Codex app-server threads.

Inspect what auth they contain:

for f in /data/.openclaw/agents/main/sessions/*.codex-app-server.json; do
  echo "--- $f"
  jq -r '.authProfileId // "NO authProfileId"' "$f"
done

At this point I’d move them aside and force fresh Codex thread bindings:

mkdir -p /data/.openclaw/backup-codex-bindings
mv /data/.openclaw/agents/main/sessions/*.codex-app-server.json /data/.openclaw/backup-codex-bindings/

Then redeploy/recreate the Coolify container and test in Telegram:

#
/new
/status

These files are not your main transcripts; they’re only Codex app-server sidecar bindings. Moving them aside is recoverable and should force OpenClaw to start clean Codex app-server threads.

If it still errors with openai:default after that, I’m leaning hard toward a 2026.5.7 Codex harness bug: /status resolves openai-codex:ev@gmail.com, but the harness path passes openai:default.

primal plume
#

i also ran rm -f /data/.openclaw/agents/main/sessions/*.codex-app-server.json

vital flickerBOT
#

Good — that removes the stale Codex thread bindings from the equation.

Now do a full Coolify redeploy/recreate of the container, not just openclaw gateway restart, then test:

printenv OPENCLAW_AGENT_RUNTIME
openclaw config get agents.defaults.agentRuntime
openclaw config get agents.defaults.model
ls /data/.openclaw/agents/main/sessions/*.codex-app-server.json 2>/dev/null | head

Then in Telegram:

/new
/status
#

Expected before the first real Codex turn: the ls ...codex-app-server.json command may be empty. After a turn, new sidecar files can appear — that’s fine.

If it still fails with:

Codex app-server auth profile "openai:default" must belong to provider "openai-codex"

while /status shows:

🔑 oauth (openai-codex:ev@gmail.com ...)
Runtime: OpenAI Codex

then I’d stop poking config and file it as a bug against 2026.5.7 / coollabsio image. That exact contradiction is the smoking gun: status resolves one auth profile, harness startup receives another.

primal plume
#

2026-05-14T15:33:42.441+00:00 [diagnostic] lane task error: lane=cron-nested durationMs=4418 error="Error: Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias."
2026-May-14 15:33:42
2026-05-14T15:33:42.442+00:00 [diagnostic] lane task error: lane=session:agent:main:cron:6347b8be-82cc-413d-b2cb-1b04973dd184:run:bb35caf6-42c7-49df-a6b5-a4bcb8b18d09 durationMs=4419 error="Error: Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias."


help me switch back to pi


write an issue i can copy paste to github

vital flickerBOT
#

Yep — let’s bail out of Codex harness cleanly.

Switch back to PI

In Coolify/container env, change:

OPENCLAW_AGENT_RUNTIME=pi

Or remove OPENCLAW_AGENT_RUNTIME entirely, but setting pi is safer while debugging.

Then run inside the container:

openclaw config set agents.defaults.agentRuntime '{"id":"pi"}' --strict-json
openclaw config set plugins.entries.codex.enabled false
openclaw gateway restart
#

If you’re using OpenAI API key direct PI, use an API-available model, e.g.:

openclaw config set agents.defaults.model 'openai/gpt-5.4'

If you specifically want Codex OAuth through PI instead of native Codex app-server, use:

openclaw config set agents.defaults.model 'openai-codex/gpt-5.5'

Then redeploy/recreate the Coolify container.

Verify:

printenv OPENCLAW_AGENT_RUNTIME
openclaw config get agents.defaults.agentRuntime
#
openclaw config get agents.defaults.model
openclaw config get plugins.entries.codex.enabled

Expected:

pi
{ "id": "pi" }
false

Then in Telegram:

#
/new
/status

GitHub issue to copy/paste

Title:

Codex harness receives openai:default auth profile even when /status resolves openai-codex OAuth profile

Body:

## Summary
#
On OpenClaw 2026.5.7 using the `coollabsio/openclaw` container image, native Codex harness fails before reply because the Codex app-server path receives `openai:default`, even though `/status` shows the active model/auth/runtime as `openai/gpt-5.5` with `openai-codex:ev@gmail.com` OAuth and `Runtime: OpenAI Codex`.

## Version / environment

- OpenClaw: `2026.5.7 (eeef486)`
- Deployment: `coollabsio/openclaw` container via Coolify
- State dir/config path: `/data/.openclaw/openclaw.json`
- Agent dir: `/data/.openclaw/agents/main/agent`
- Channel/session affected: Telegram direct session and cron/nested lane

## Relevant config

```bash
openclaw config get agents.defaults.agentRuntime
#

```json
{
  "id": "codex"
}

/status showed:

🧠 Model: openai/gpt-5.5 · 🔑 oauth (openai-codex:ev@gmail.com (...))
⚙️ Execution: direct · Runtime: OpenAI Codex · Think: medium · Text: low

openclaw models status showed Codex OAuth profiles, including:

#

```text
openai-codex:ev@gmail.com=OAuth (...)
openai-codex:aa@hotmail.com=OAuth (...)

Error

[agents/harness] Codex agent harness failed; not falling back to embedded PI backend
[diagnostic] lane task error: lane=main durationMs=3097 error="Error: Codex app-server auth profile \"openai:default\" must belong to provider \"openai-codex\" or a supported alias."
Embedded agent failed before reply: Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias.

Also reproduced from cron/nested lane:

#

```text
[diagnostic] lane task error: lane=cron-nested durationMs=4418 error="Error: Codex app-server auth profile \"openai:default\" must belong to provider \"openai-codex\" or a supported alias."

Attempts / observations

  • Enabled Codex plugin.
  • Set agents.defaults.agentRuntime to { "id": "codex" }.
  • Set container env OPENCLAW_AGENT_RUNTIME=codex and restarted/redeployed.
  • /status correctly showed openai-codex:ev@gmail.com OAuth and Runtime: OpenAI Codex.
  • Removed Codex app-server sidecar bindings:
rm -f /data/.openclaw/agents/main/sessions/*.codex-app-server.json
#

- Checked for stale sidecar refs:

```bash
grep -RIl 'openai:default' /data/.openclaw/agents/main/sessions/*.codex-app-server.json

This returned no matches.

Despite that, the harness error still says the Codex app-server auth profile is openai:default.

Expected behavior

If /status resolves the active auth profile as openai-codex:ev@gmail.com and runtime as OpenAI Codex, the Codex harness/app-server startup should receive that openai-codex:* profile, not openai:default.

#
## Actual behavior

The visible status/auth resolution and the Codex harness startup auth profile disagree:

- Status: `openai-codex:ev@gmail.com`
- Harness error: `openai:default`

## Impact

Native Codex harness cannot run; agent turns and cron/nested tasks fail before reply. I had to switch back to PI as a workaround.
primal plume
#

did the issue you write be according to the template? btw i started using openclaw with api key and pi and then switched to oauth and tried codex harness but didnt work with these errors so switched back and then it was fine till one day it suddenly came back and then i came to you

and finally now back to working again with pi and codex oauth

vital flickerBOT
#

Good catch — the one I wrote was useful, but not exactly in the GitHub bug template order. I checked .github/ISSUE_TEMPLATE/bug_report.yml; here’s a cleaner copy/paste version that matches it.

Title:

[Bug]: Codex harness receives openai:default auth profile while status shows openai-codex OAuth

Bug type:

Regression (worked before, now fails)

Beta release blocker:

No
#

Summary:

After switching between PI/API-key, Codex OAuth, and native Codex harness on OpenClaw 2026.5.7, native Codex harness started failing because the harness receives openai:default even though /status resolves openai-codex OAuth; switching back to PI + Codex OAuth works around it.

Steps to reproduce:

1. Start from a working OpenClaw setup using PI with an OpenAI API key (`openai:default`).
2. Add Codex OAuth profiles with `openclaw models auth login --provider openai-codex`.
3. Try native Codex harness by enabling the Codex plugin and setting Codex runtime (`agents.defaults.agentRuntime.id=codex` and/or `OPENCLAW_AGENT_RUNTIME=codex`).
4. Observe native Codex harness failing with `Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias.`
5. Switch back to PI + Codex OAuth; it works again.
6. Later, without intentionally switching back to native Codex harness, the same Codex app-server auth-profile error reappeared in agent/cron lanes until switching back to PI again.

Expected behavior:

#
When /status resolves the active auth profile as openai-codex OAuth, native Codex harness should receive an openai-codex:* auth profile. When configured for PI, the native Codex app-server harness should not be used.

Actual behavior:

/status showed Runtime: OpenAI Codex and oauth (openai-codex:ev@gmail.com), but the Codex harness failed before reply because app-server startup/resume received openai:default. Switching back to PI + Codex OAuth worked around the issue.

OpenClaw version:

2026.5.7 (eeef486)

Operating system:

#
Linux container via coollabsio/openclaw on Coolify

Install method:

Docker/container image: coollabsio/openclaw via Coolify

Model:

openai/gpt-5.5 for native Codex harness testing; openai-codex/gpt-5.5 or PI + Codex OAuth as workaround

Provider / routing chain:

#
OpenClaw Telegram/cron agent -> OpenAI/Codex routing. Native Codex harness path unexpectedly receives openai:default; PI + Codex OAuth path works.

Additional provider/model setup details:

Observed auth profiles from `openclaw models status` included:

- `openai:default` from OPENAI_API_KEY / API key profile
- `openai-codex:ev@gmail.com` OAuth
- `openai-codex:aa@hotmail.com` OAuth

`/status` during the failure showed:

```text
Model: openai/gpt-5.5 · oauth (openai-codex:ev@gmail.com (...))
Execution: direct · Runtime: OpenAI Codex
#

`agents.defaults.agentRuntime` was set to:

```json
{ "id": "codex" }

Later workaround was switching back to PI and Codex OAuth, which is now working again.


Logs, screenshots, and evidence:
```shell
2026-05-14T15:26:14.164+00:00 [agents/harness] Codex agent harness failed; not falling back to embedded PI backend
2026-05-14T15:26:14.166+00:00 [diagnostic] lane task error: lane=main durationMs=3021 error="Error: Codex app-server auth profile \"openai:default\" must belong to provider \"openai-codex\" or a supported alias."
Embedded agent failed before reply: Codex app-server auth profile "openai:default" must belong to provider "openai-codex" or a supported alias.
#

2026-05-14T15:33:42.441+00:00 [diagnostic] lane task error: lane=cron-nested durationMs=4418 error="Error: Codex app-server auth profile \"openai:default\" must belong to provider \"openai-codex\" or a supported alias."

Impact and severity:

Affected: OpenClaw container deployment using Telegram direct sessions and cron/nested lanes.
Severity: High when native Codex harness is selected, because agent turns fail before reply.
Frequency: Reproduced repeatedly while native Codex harness was active; later reappeared unexpectedly after previously switching back.
Consequence: Native Codex harness cannot be used reliably; workaround is PI + Codex OAuth.

Additional information:

I started with OpenClaw using an OpenAI API key and PI. Later I switched to Codex OAuth and tried native Codex harness, but hit the openai:default vs openai-codex auth-profile error. I switched back and it worked for a while. Later, without making intentional Codex harness changes, the same error returned in main and cron/nested lanes. After switching back to PI + Codex OAuth again, it is working.
#

Troubleshooting already tried:

- Verified `OPENCLAW_AGENT_RUNTIME=codex` inside the container while testing Codex runtime.
- Verified `/status` showed `Runtime: OpenAI Codex` and `oauth (openai-codex:ev@gmail.com)`.
- Removed Codex app-server sidecar bindings:

```bash
rm -f /data/.openclaw/agents/main/sessions/*.codex-app-server.json
  • Checked for stale sidecars containing openai:default:
grep -RIl 'openai:default' /data/.openclaw/agents/main/sessions/*.codex-app-server.json