Codex harness default change to pi harness

[solemn vessel]

After latest update version OpenClaw 2026.5.18 (50a2481) when using openai models it seems to be set on codex harness even though when doing /status it shows am on pi harness also all commands done through the codex harness require approvals how can i switch to pi harness and how can i make commands run without approvals on each turn

[potent shore]

I checked the current docs. In the newer runtime split, this is expected-ish: for agent turns, openai/* can be claimed by the bundled codex runtime when the Codex plugin is enabled. Provider/model and runtime are separate now.

To force PI for an OpenAI model, keep the model ref as openai/<your-model> and set runtime policy on the provider or model, not the old whole-agent/runtime pin:

{
  agents: {
    defaults: {
      model: "openai/<your-model>",
      models: {
        "openai/<your-model>": {
          agentRuntime: { id: "pi" }
        }
      }
    }
  }

[potent shore]

}

Then restart the gateway and start a fresh session with /new or /reset. Old whole-agent/session runtime pins are ignored now, and stale legacy state can be cleaned with:

openclaw doctor --fix

For the approvals: if you only want it for the current chat/session, use:

/exec security=full ask=off

or the stronger break-glass shortcut:

[potent shore]

/elevated full

For a local machine-wide shortcut:

openclaw exec-policy preset yolo

If exec is happening on a node, the local shortcut will not sync to the node; use openclaw approvals set --node <id|name|ip> ... instead.

Docs:
https://docs.openclaw.ai/concepts/agent-runtimes
https://docs.openclaw.ai/plugins/codex-harness
https://docs.openclaw.ai/tools/exec-approvals
https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

[solemn vessel]

can i disable codex harness plugin so it defaults to pi harness always

[potent shore]

Yes. You can disable the bundled Codex harness plugin, then openai/* agent turns should fall back to PI unless some provider/model runtime policy still says otherwise.

In your OpenClaw config:

{
  plugins: {
    entries: {
      codex: {
        enabled: false
      }
    }
  }
}

If you use plugins.allow, also remove "codex" from that allowlist. Then restart the gateway and use /new or /reset in the chat you’re testing, because runtime/session state can otherwise make this look unchanged.

[potent shore]

I’d also run:

openclaw doctor --fix

That cleans old whole-agent/runtime pins and legacy openai-codex/* model refs that can make the runtime selection confusing.

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

[solemn vessel]

how to check first if it is enabled

[potent shore]

Quick checks:

openclaw config get plugins.entries.codex.enabled
openclaw config get plugins.allow
openclaw plugins list --enabled | grep codex

How to read it:

• If plugins.entries.codex.enabled prints true, it’s explicitly enabled.
• If it prints false, it’s explicitly disabled.
• If it prints nothing/null, then check openclaw plugins list --enabled to see the effective loaded state.
• If plugins.allow is set and includes codex, the allowlist permits it; if the allowlist is set and does not include codex, it should be gated out.

From chat, /codex status is also a useful runtime check: if the Codex command surface is unavailable or cannot connect, that points at the plugin not being active/configured.

[solemn vessel]

whats a 1 liner command to disable it

[potent shore]

Use:

openclaw plugins disable codex && openclaw gateway restart

Then in the chat/session you’re testing, run /reset or /new so the next turn resolves the runtime fresh.

[solemn vessel]

I tried elevated and exec full still get popup plugin approval required for codex runtime

[potent shore]

Right, that makes sense: /elevated full and /exec security=full ask=off only affect OpenClaw exec approvals. They do not override Codex runtime/native plugin approvals.

If your goal is “no Codex runtime at all, always PI”, do this, then reset the chat:

openclaw plugins disable codex && openclaw gateway restart

Then in the affected chat:

/reset

If you still want the Codex harness but want to disable native Codex plugin/app approvals specifically, turn off native Codex plugins:

[potent shore]

openclaw config set plugins.entries.codex.config.codexPlugins.enabled false && openclaw gateway restart

Then /reset or /new.

To verify what’s still active:

openclaw plugins list --enabled | grep codex
openclaw config get plugins.entries.codex.config.codexPlugins.enabled

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

[solemn vessel]

I want it on but on yolo mode jot approval everytime

[potent shore]

Got it. Keep Codex enabled, but force its app-server posture back to YOLO:

openclaw plugins enable codex && openclaw config set plugins.entries.codex.config.appServer.mode yolo && openclaw config set plugins.entries.codex.config.appServer.approvalPolicy never && openclaw config set plugins.entries.codex.config.appServer.sandbox danger-full-access && openclaw config set plugins.entries.codex.config.appServer.approvalsReviewer user && openclaw gateway restart

Then run /reset or /new in the affected chat.

Two caveats:

• If an OpenClaw sandbox is active, Codex danger-full-access is intentionally narrowed to workspace-write.
• If the popup is from native Codex plugin apps rather than shell/file approval, that is a separate layer. You can turn native Codex plugins off with:

openclaw config set plugins.entries.codex.config.codexPlugins.enabled false && openclaw gateway restart

Check current values with:

[potent shore]

openclaw config get plugins.entries.codex.config.appServer

[solemn vessel]

working good now is their a 1 liner to switch harness when i want

[potent shore]

Yep. For all openai/* agent turns, use provider-scoped runtime switching:

PI:

openclaw config set models.providers.openai.agentRuntime.id pi && openclaw gateway restart

Codex:

openclaw plugins enable codex && openclaw config set models.providers.openai.agentRuntime.id codex && openclaw gateway restart

After either switch, use /reset or /new in the chat you’re testing so it starts a fresh runtime session.

If you want to go back to OpenClaw’s default auto behavior instead of forcing either one:

[potent shore]

openclaw config unset models.providers.openai.agentRuntime && openclaw gateway restart

[solemn vessel]

and what is the default behaviour

[potent shore]

Default behavior is auto.

In practice:

• For most providers: if no runtime claims the model, OpenClaw uses PI as the compatibility runtime.
• For openai/* agent turns: OpenAI is the exception. If the bundled codex plugin is enabled and available, unset/auto resolves to the Codex harness by default.
• If the Codex plugin is disabled or unavailable, openai/* falls back to PI.
• Explicit config wins: models.providers.openai.agentRuntime.id = "pi" forces PI, and "codex" forces Codex/fails clearly if unavailable.

So the “stock” behavior after recent updates is basically: OpenAI model + Codex plugin enabled = Codex runtime.

[solemn vessel]

The model did not produce a response before the model idle timeout. Please try again, or increase models.providers.<id>.timeoutSeconds for slow local or self-hosted providers. If agents.defaults.timeoutSeconds or a run-specific timeout is lower, raise that ceiling too; provider timeouts cannot extend the whole agent run.

[potent shore]

That error means the selected provider/model went quiet long enough to hit the idle watchdog.

If this is your OpenAI/Codex setup, try:

openclaw config set models.providers.openai.timeoutSeconds 300 && openclaw config set agents.defaults.timeoutSeconds 300 && openclaw gateway restart

Then /reset or /new the chat and retry.

If you are using a different provider id, replace openai with that provider id:

openclaw config set models.providers.<id>.timeoutSeconds 300 && openclaw config set agents.defaults.timeoutSeconds 300 && openclaw gateway restart

Important bit: models.providers.<id>.timeoutSeconds can’t exceed the whole agent run ceiling. So if agents.defaults.timeoutSeconds is lower, the agent run still gets cut off first.

[potent shore]

You can check current values with:

openclaw config get models.providers.openai.timeoutSeconds
openclaw config get agents.defaults.timeoutSeconds

[solemn vessel]

Config path not found: models.providers.openai.timeoutSeconds. Run openclaw config validate to inspect config shape.

[potent shore]

Right, that happens when there isn’t already an explicit models.providers.openai object in your config. Use the additive JSON merge form instead:

openclaw config set models.providers.openai '{"timeoutSeconds":300}' --strict-json --merge && openclaw config set agents.defaults.timeoutSeconds 300 && openclaw gateway restart

Then /reset or /new before retrying.

If openai still errors because it’s a bundled provider entry rather than a local config entry, check your selected provider id with:

openclaw config get agents.defaults.model

Then set the timeout on that provider id with the same merge pattern:

[potent shore]

openclaw config set models.providers.<id> '{"timeoutSeconds":300}' --strict-json --merge

[solemn vessel]

never faced this issue with pi harness though the timeout

[potent shore]

That tracks. PI and Codex don’t have identical runtime behavior.

With PI, OpenClaw owns more of the model loop directly. With Codex harness, OpenClaw is talking to Codex app-server, and there’s an extra runtime/app-server layer with its own “went quiet after a tool/action” behavior. So a turn that survives under PI can still hit the Codex idle watchdog if Codex app-server stops emitting progress for long enough.

If you want stability over Codex-native behavior, forcing PI for OpenAI is reasonable:

openclaw config set models.providers.openai '{"agentRuntime":{"id":"pi"}}' --strict-json --merge && openclaw gateway restart

Then /reset.

If you want to keep Codex, raising both the provider timeout and agents.defaults.timeoutSeconds is the right workaround. If it still times out after that, I’d file it as a Codex harness bug with logs and version info: https://github.com/openclaw/openclaw/issues

[solemn vessel]

openclaw config set models.providers.openai.agentRuntime.id pi && openclaw gateway restart

is this same as above

[potent shore]

Same intended end state, yes: both set

models.providers.openai.agentRuntime.id = "pi"

But on your config, the dotted one can fail if models.providers.openai does not already exist. You already hit that pattern with timeoutSeconds.

So use the merge form; it creates/merges the provider object safely:

openclaw config set models.providers.openai '{"agentRuntime":{"id":"pi"}}' --strict-json --merge && openclaw gateway restart

Then /reset or /new in the chat.

[solemn vessel]

how to check current harness then

[potent shore]

Best check is from the chat/session itself:

/status

Look for the runtime/harness line. If it says codex, that session is using Codex. If it says pi, it’s using PI.

Config-side checks:

openclaw config get models.providers.openai.agentRuntime
openclaw plugins list --enabled | grep codex
openclaw config get agents.defaults.model

How to read it:

[potent shore]

• agentRuntime.id: "pi" means OpenAI is forced to PI.
• agentRuntime.id: "codex" means OpenAI is forced to Codex.
• If agentRuntime is unset and Codex plugin is enabled, openai/* usually defaults to Codex.
• If you just changed config, use /reset or /new first, because the existing session may still reflect the previous runtime.

[solemn vessel]

in status it says pi codex harness is enabled though and

Config path not found: models.providers.openai.agentRuntime. Run openclaw config validate to inspect config shape.

[potent shore]

That combination is normal:

• /status saying pi = this current session is running on PI.
• Codex harness enabled = the Codex plugin is available, not necessarily selected for this session.
• Config path not found: models.providers.openai.agentRuntime = you have no explicit OpenAI runtime override in config. That’s not an error state; it just means it’s unset/default.

If you want to check without the path error, ask for the parent object:

openclaw config get models.providers.openai

If that path is also missing, it just means you’re using the bundled/default OpenAI provider config.

To force PI explicitly so there’s no ambiguity:

[potent shore]

openclaw config set models.providers.openai '{"agentRuntime":{"id":"pi"}}' --strict-json --merge && openclaw gateway restart

Then /reset. After that, /status should still say PI, but now it’s because config forces it rather than because the current session resolved that way.

[solemn vessel]

Config path not found: models.providers.openai. Run openclaw config validate to inspect config shape.

[potent shore]

That just means your config has no local models.providers override at all; OpenClaw is using the bundled provider catalog.

For checking, use:

openclaw config get models

or just trust /status for the active session runtime.

To create the OpenAI provider override and force PI, use this form at the parent map level:

openclaw config set models.providers '{"openai":{"agentRuntime":{"id":"pi"}}}' --strict-json --merge && openclaw gateway restart

Then /reset or /new.

[potent shore]

After that, this should no longer be missing:

openclaw config get models.providers.openai

[solemn vessel]

how would i confirm though am on pi or codex i mean now even though in status it says pi i know for a fact am on codex harness

[potent shore]

The thing to trust is the Runtime line in /status, not “Codex harness enabled”.

There are three different things that can look like “Codex”:

• Codex plugin enabled = available only.
• openai-codex auth/profile = Codex/ChatGPT auth route, can still be used by PI.
• Codex harness/runtime = actual low-level executor.

So if /status says Runtime is PI/OpenClaw Pi Default, you are on PI even if Codex is enabled or your auth profile says openai-codex.

Best confirmation:

/status

Look specifically for Runtime:, not model/provider/plugin lines.

[potent shore]

CLI side, get the machine-readable status and filter it:

openclaw status --json --all | grep -Ei 'runtime|harness|codex|execution|model'

If that says PI but you still get a Codex app-server/native plugin approval popup, then that sounds like a status/reporting bug or stale session state. Do this once:

openclaw doctor --fix && openclaw gateway restart

then /reset and re-check /status.

If it still says PI while Codex app-server approvals appear, I’d file that with the exact /status output and the approval screenshot/logs: https://github.com/openclaw/openclaw/issues

[solemn vessel]

runtime."
"detail": "Unpinned plugin index install records:\n- codex (@openclaw/codex)",

[potent shore]

That line is about the plugin install record, not the active agent runtime.

Unpinned plugin index install records: codex (@openclaw/codex) means the Codex plugin package is installed but not pinned to an exact version/source. It does not prove the current session is running on the Codex harness.

For runtime, look for the actual Runtime field from status. Try a less noisy check:

openclaw status --json --all | grep -Ei '"runtime"|"agentRuntime"|"execution"|"model"'

And in chat:

/status

If the status runtime says PI/OpenClaw Pi Default, that session is PI. If you want to remove the Codex plugin install warning/noise entirely, disable or uninstall Codex, but that’s separate from runtime selection.

[solemn vessel]

openclaw plugins list --enabled | grep codex
openclaw config get plugins.entries.codex.config.codexPlugins.enabled
│ Codex │ codex │ openclaw │ enabled │ ~/.openclaw/npm/node_modules/@openclaw/codex/dist/index. │ 2026.5.18 │

🦞 OpenClaw 2026.5.18 (50a2481) — More integrations than your therapist's intake form.

false

[potent shore]

That output means:

• Codex harness plugin: enabled/available.
• Native Codex plugin apps: disabled (codexPlugins.enabled = false).

So if you still see Codex-ish behavior, it’s from the harness itself, not native Codex plugin apps.

To confirm what the current chat is actually using, /status is still the best source. If it says Runtime = PI, then you’re not on the Codex harness even though the plugin is enabled.

If you want Codex installed but force OpenAI turns to PI, set the provider runtime override:

openclaw config set models.providers '{"openai":{"agentRuntime":{"id":"pi"}}}' --strict-json --merge && openclaw gateway restart

Then /reset, and check /status again.

[solemn vessel]

Codex harness plugin: enabled/available.,
Native Codex plugin apps: disabled (codexPlugins.enabled = false).,

am confused what this means

[potent shore]

Yeah, the naming is confusing. There are two separate Codex things:

1. Codex harness plugin
   This is the main Codex runtime integration. If OpenClaw chooses the Codex runtime, this is what runs the agent turn through Codex app-server instead of PI.

2. Native Codex plugin apps
   These are extra Codex-side apps/plugins, like migrated OpenAI-curated Codex plugins. Yours are disabled because codexPlugins.enabled = false.

So your current state means:

• Codex runtime support is installed and available.
• Extra native Codex apps are off.
• Whether this chat is using PI or Codex still depends on runtime selection, shown by /status.

Simple version:

[potent shore]

Codex harness plugin enabled = Codex can be used as the engine.
codexPlugins.enabled false = no extra Codex app plugins.
Runtime in /status = what engine this chat is actually using.

If you want zero Codex runtime possibility, disable the harness plugin. If you want Codex available but this OpenAI model to use PI, force agentRuntime.id: "pi".

[solemn vessel]

Error: Config validation failed: models.providers.openai.baseUrl: Invalid input

[potent shore]

Yep, that error is from the provider-level override I suggested. Back that out first:

openclaw config unset models.providers.openai && openclaw config validate

Then use a model-scoped runtime override instead of models.providers.openai. First check your exact model ref:

openclaw config get agents.defaults.model

Then set PI for that exact model, for example:

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

[potent shore]

Replace openai/gpt-5.5 with whatever your agents.defaults.model shows.

Then /reset or /new.

Sorry for the bad provider-level command there. The docs show provider runtime policy, but your config/schema path is rejecting that built-in provider override shape, so model-scoped is the cleaner route.

[solemn vessel]

openclaw config unset models.providers.openai

what does this do

[potent shore]

It removes the local config override at:

models.providers.openai

In your case, that’s the bad override that is causing:

models.providers.openai.baseUrl: Invalid input

It does not delete OpenAI support from OpenClaw. The built-in OpenAI provider catalog still exists. It only removes the custom provider entry you added to your config.

So the repair flow is:

[potent shore]

openclaw config unset models.providers.openai
openclaw config validate

If validation passes, then add the runtime preference somewhere safer, like the exact model entry under agents.defaults.models.

[solemn vessel]

Config path not found: models.providers.openai. Nothing was changed. Run openclaw config get <path> first if you are unsure of the path.

[potent shore]

That’s okay. It means there is no saved models.providers.openai override to remove. So either the earlier failed command never wrote anything, or the bad value is somewhere else.

Do this next:

openclaw config validate

If validation passes, ignore the unset error and use the model-scoped override instead:

openclaw config get agents.defaults.model

Then replace the model below with that exact openai/... value:

[potent shore]

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

If openclaw config validate still complains about models.providers.openai.baseUrl, find where it’s coming from with:

openclaw config file
openclaw config get models

Then paste that models block here. Something else is defining an invalid OpenAI provider override.

[solemn vessel]

⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

I noticed that I randomly get this message from time to time. I am on the last update

[potent shore]

That exact text is OpenClaw’s generic agent-run failure fallback. It usually means the underlying model/runner errored before OpenClaw could turn it into a more specific message, so “latest update” isn’t enough to diagnose it.

First thing: what does openclaw --version show?

Then, right after it happens, grab the real error from logs:

openclaw logs --follow

Or run the quick triage ladder:

openclaw status
openclaw status --all
openclaw gateway probe
openclaw gateway status
openclaw doctor
openclaw channels status --probe

[potent shore]

If the same thread has been going for a while, also try /new once. The FAQ notes stale/large sessions can cause weird session-history or context issues, and /new starts a fresh session for that chat.

Docs: https://docs.openclaw.ai/help/troubleshooting and https://docs.openclaw.ai/help/faq

This log points to two things:

1. The actual upstream request to ChatGPT/Codex timed out after ~120s:

fetch timeout reached ... chatgpt.com/backend-api/codex/responses
model=gpt-5.5 ... message=request timed out

2. While that request was hung and OpenClaw released the embedded prompt lock, the same session file changed:

EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released

So this looks less like a random Discord/Telegram error and more like: one run times out, then another message/run touches the same session before the first run can finish recovery. The Telegram ENOENT ... .processing -> .json line is probably secondary cleanup/spool noise after the failure, not the first cause.

Immediate workaround:

• send /new in that Telegram DM/thread to force a clean session

• avoid sending a second message while a long Codex run is still pending
• restart the gateway if it keeps happening after /new

Also: please still paste openclaw --version. If this reproduces on the latest main/release with a fresh /new, it’s good GitHub issue material with exactly this log snippet: https://github.com/openclaw/openclaw/issues

Docs for the related bits: https://docs.openclaw.ai/concepts/agent-loop and https://docs.openclaw.ai/concepts/model-providers

[solemn vessel]

How do we disable the Codex harness ?

[potent shore]

If by “Codex HORMS” you mean the Codex harness, force OpenClaw back to the PI harness and start a fresh session:

{
  agents: {
    defaults: {
      embeddedHarness: {
        runtime: "pi",
        fallback: "pi",
      },
    },
  },
}

Then restart the gateway and send /new in the affected chat. Harness choice is pinned per session, so changing config won’t affect an already-pinned session until /new//reset.

[potent shore]

If you had env overrides set, remove/avoid these too:

OPENCLAW_AGENT_RUNTIME=codex
OPENCLAW_AGENT_HARNESS_FALLBACK=none

Docs: https://docs.openclaw.ai/gateway/configuration-reference#agentsdefaultsembeddedharness and https://docs.openclaw.ai/plugins/codex-harness

[solemn vessel]

need 1 liner to disable it

[potent shore]

One-liner:

openclaw config set agents.defaults.embeddedHarness '{"runtime":"pi","fallback":"pi"}' --strict-json && openclaw gateway restart

Then send /new in the affected chat because harness choice is pinned per session.

[solemn vessel]

Couldn't we just disable the Codex plugin itself and that will force us to use the pi harness?

[potent shore]

Yes, disabling the codex plugin should stop the Codex app-server harness from being selected, and with the normal fallback: "pi" policy OpenClaw will use PI when it can.

One-liner:

openclaw plugins disable codex && openclaw gateway restart

Then send /new in the affected chat, because existing sessions can stay harness-pinned.

Small caveat: if your model is configured as native-harness style openai/gpt-5.5, switch it to the PI OAuth route openai-codex/gpt-5.5; otherwise disabling the plugin may remove the thing that made that route work.

[solemn vessel]

Config warnings:

• plugins.entries.codex: plugin disabled (disabled in config) but config is present

[potent shore]

That warning is expected: the plugin is disabled, but its saved config block is still there so OpenClaw warns instead of deleting it.

If you just want to silence the warning while keeping Codex disabled:

openclaw config unset plugins.entries.codex.config && openclaw gateway restart

I’d avoid unsetting all of plugins.entries.codex unless you confirm the plugin stays disabled afterward, because the enabled: false flag may live there too.

[solemn vessel]

I mean, right now it is disabled, so I should be able to use the pi harness.

[potent shore]

Yes, with the Codex plugin disabled, OpenClaw should use the PI harness as long as you’re not still forcing Codex elsewhere.

Check these two things:

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

Good PI-ish state is either no embeddedHarness override, or:

{ runtime: "auto", fallback: "pi" }

or:

{ runtime: "pi", fallback: "pi" }

[potent shore]

Also send /new in that chat. Existing sessions can stay pinned to the old harness, so a disabled plugin does not necessarily change the already-running session.

[solemn vessel]

/model <provider/model> --runtime <runtime> to switch harnesses

[potent shore]

I checked current source/docs: /model <provider/model> --runtime <runtime> does not look supported right now. /model only accepts the model id, and harness runtime is currently config/env controlled via agents.defaults.embeddedHarness / OPENCLAW_AGENT_RUNTIME.

That command shape would be a nice feature request, though. It would need to handle the session pinning rule too, probably by either forcing a /new-style reset or refusing to switch runtime on an already-pinned session.

Current working path is still:

openclaw config set agents.defaults.embeddedHarness '{"runtime":"pi","fallback":"pi"}' --strict-json && openclaw gateway restart

Then /new in the chat.

[solemn vessel]

⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

I still keep getting this even after I'm user shared even after disabling the plugin. I don't know why.

[potent shore]

Disabling the Codex plugin only removes the native Codex app-server harness. It does not stop the PI runner from using the openai-codex/gpt-5.5 provider path, which can still hit chatgpt.com/backend-api/... and still timeout/fail.

At this point I’d separate “which harness” from “which provider/model is failing.” Please paste these outputs:

openclaw --version
openclaw config get agents.defaults.embeddedHarness
openclaw config get agents.defaults.model
openclaw config get plugins.entries.codex.enabled

And right after the next failure, paste the nearby lines from:

openclaw logs --follow

Also run /status in the affected chat before the next prompt. If it still shows Fast · codex, that chat is still pinned or not actually on the config you think it is. If it shows PI but the logs still mention openai-codex / chatgpt.com/backend-api, then the remaining issue is the Codex OAuth provider request timing out, not the Codex harness.

[solemn vessel]

Now Ray sent you the lines a couple of messages ago. They are the same. I don't know.

[potent shore]

Right, if the lines are still the same, then the important part is this:

fetchWithSsrFGuard ... https://chatgpt.com/backend-api/codex/responses
model=gpt-5.5 ... request timed out

That means you’re still using the Codex OAuth provider path from PI (openai-codex/gpt-5.5), even if the Codex plugin/harness is disabled. So the plugin change probably worked, but it didn’t change the model/provider route.

To avoid that path, switch the default model away from openai-codex/gpt-5.5 to a non-Codex provider you have auth for, then restart + /new. Example shape:

openclaw config set agents.defaults.model.primary "anthropic/claude-opus-4-6" && openclaw gateway restart

Use whatever provider/model you actually have configured. I’m not listing a model menu from memory here because that gets stale fast; openclaw models status / openclaw models list should show what your gateway can use.

If you want to stay on GPT-5.5 via ChatGPT/Codex OAuth, then the remaining problem is the upstream Codex request timing out after 120s, not the harness. In that case the best workaround is shorter prompts, /new, or trying again later; if it keeps happening reproducibly, file it with the timeout + session-takeover logs: https://github.com/openclaw/openclaw/issues

[solemn vessel]

Can you check if this is a known issue?

[potent shore]

Yes, the EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released part is a known/recent issue family.

Relevant issues/PR I found:

• #85306: Telegram direct turns hitting this exact session-takeover error. Closed + locked as resolved. https://github.com/openclaw/openclaw/issues/85306
• #84250: merged fix, “tolerate in-process session writes during prompt release”, merged 2026-05-21. https://github.com/openclaw/openclaw/pull/84250
• #86370: follow-up saying it still recurred on 2026.5.22 for fresh sessions / long or tool-heavy turns after #84250. It’s also closed now. https://github.com/openclaw/openclaw/issues/86370

I did not find a separate public issue for the exact chatgpt.com/backend-api/codex/responses 120s timeout string, but your full log fits the known pattern: upstream/model request hangs or runs long, then the embedded session fence trips with the takeover error.

If you’re truly on a build newer than the #84250 fix and still reproducing, I’d open a new GitHub issue with:

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

plus the same timeout + EmbeddedAttemptSessionTakeoverError log block. This looks issue-worthy, not just config confusion.

[solemn vessel]

OpenClaw 2026.5.22 (a374c3a)

[potent shore]

Yep, that’s the exact version from the follow-up known issue #86370: 2026.5.22 / a374c3a.

There are newer builds after that: I see v2026.5.24-beta.2 as the newest GitHub release, and newer alpha tags like v2026.5.25-alpha.2. So I would try updating past 2026.5.22 first.

If you want the least spicy path, use the newer beta rather than alpha. After updating:

openclaw --version
openclaw gateway restart

Then /new in the affected Telegram chat and retry the same prompt.

If it still reproduces on 2026.5.24-beta.2 or newer, open a new issue and mention it reproduces after #84250 / #86370 on that newer version. That’s strong signal.

[solemn vessel]

How do you update to these versions? The way I update is from OpenFlow update. I don't think those are their yet.

[potent shore]

Yeah, the UI/OpenFlow updater may only be offering stable right now. I checked npm: latest is still 2026.5.22, but beta is 2026.5.24-beta.2.

From a shell on the gateway machine, use:

openclaw update --tag beta

Or pin the exact beta:

openclaw update --tag 2026.5.24-beta.2

Preview first if you want:

openclaw update --tag beta --dry-run

[potent shore]

After it updates:

openclaw --version
openclaw gateway restart

Then send /new in the affected chat.

Docs: https://docs.openclaw.ai/install/updating and https://docs.openclaw.ai/install/development-channels

[solemn vessel]

What will the dry run do?

[potent shore]

--dry-run only previews the update plan. It should not install anything, change config, restart the gateway, or run migrations.

For this case:

openclaw update --tag beta --dry-run

It should show things like: current version/install kind, target version (2026.5.24-beta.2 if npm beta still points there), planned package/git actions, whether it would run doctor, whether it would restart, and any downgrade/confirmation warnings.

If the preview looks sane, run the same command without --dry-run:

openclaw update --tag beta

[solemn vessel]

Before updating, is the issue resolved within this beta version?

[potent shore]

I can’t honestly say “yes, confirmed fixed” from the release notes.

What I found:

• Your version, 2026.5.22 (a374c3a), is exactly the version in #86370 where the takeover error still reproduced after #84250.
• 2026.5.24-beta.2 is newer, but its release notes do not explicitly mention EmbeddedAttemptSessionTakeoverError, #85306, #86370, or a session-fence fix.
• #86370 is closed now, so there may be follow-up work in the beta, but I don’t see a clean public “fixed in 2026.5.24-beta.2” statement.

So: update to beta is a reasonable test, not a guaranteed fix. I’d do:

openclaw update --tag beta --dry-run

If it targets 2026.5.24-beta.2, update, restart, /new, and retry the same prompt. If it still fails there, file a new issue saying it reproduces on 2026.5.24-beta.2 too.

[solemn vessel]

still not fixed

[potent shore]

That’s frustrating, but useful signal. If you updated past 2026.5.22 and the same EmbeddedAttemptSessionTakeoverError still happens, it’s not just the already-closed #86370 case.

Please grab the exact post-update version:

openclaw --version

Then I’d file a fresh issue with:

• the new version
• channel: Telegram direct
• whether /new was used after update
• the same log block showing both the timeout and EmbeddedAttemptSessionTakeoverError
• link back to #86370 and say it still reproduces after the newer beta

Issue link: https://github.com/openclaw/openclaw/issues

Short-term workaround: avoid openai-codex/gpt-5.5 for that agent if you can, because your earlier logs showed the turn hanging on chatgpt.com/backend-api/codex/responses before the session fence blew up. Switch to another configured provider/model, restart, then /new.

[solemn vessel]

2:57:15+00:00 info [warn] Subagent completion direct announce failed for run 59204699-19ae-4ee8-96d3-d2f310d1b148: EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/lux/.openclaw/agents/main/sessions/7d3c9a5a-9a75-4deb-afa8-771ae9779021.jsonl
22:57:17+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.patch 2093ms conn=4e6b63b3…269a id=bcbdc701…4726
22:57:17+00:00 info [warn] Subagent announce give up (retry-limit) run=59204699-19ae-4ee8-96d3-d2f310d1b148 child=agent:main:subagent:60c4f118-e1d0-4a2b-b83d-a5e6ec05fd4a requester=agent:main:telegram:direct:1275976396 retries=3 endedAgo=302s deliveryError="EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/lux/.openclaw/agents/main/sessions/7d3c9a5a-9a75-4deb-afa8-771ae9779021.jsonl; direct-primary: EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/lux/.openclaw/agents/main/sessions/7d3c9a5a-9a75-4deb-afa8-771ae9779021.jso

[potent shore]

This new log is specifically the subagent completion delivery path, not the Codex plugin/harness path.

Key lines:

Subagent completion direct announce failed ... EmbeddedAttemptSessionTakeoverError
Subagent announce give up (retry-limit) ... retries=3

So the child subagent likely finished, but OpenClaw failed to announce the result back into the requester Telegram session because the requester session file hit the same takeover fence. That matches known issue #67777: subagent completion delivery can be lost when direct announce fails. https://github.com/openclaw/openclaw/issues/67777

This is good evidence for a fresh/update issue because it ties the current session-takeover bug to subagent delivery loss. I’d include:

• your exact openclaw --version
• this Subagent completion direct announce failed / give up (retry-limit) block
• the earlier chatgpt.com/backend-api/codex/responses timeout block if still present
• links to #67777 and #86370

Short-term: avoid subagent-heavy tasks on that Telegram session until this is fixed. Use a fresh /new, keep one foreground request at a time, and ask the main agent to do the work directly instead of spawning subagents where possible.

[solemn vessel]

EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released

I'm still getting this error. Is there any update to fix this?

[potent shore]

There has been movement here: current main/2026.5.26 includes fixes around this exact area, including tolerating OpenClaw-owned transcript writes during embedded prompt release and releasing embedded-attempt locks on every exit path. The changelog entries I found are #84250 and #86427.

First check your version:

openclaw --version

If you’re below 2026.5.26, update and restart the gateway. If you’re already on 2026.5.26 and still seeing EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released, that’s likely still a live bug or a true concurrent session writer case. Please file it with the exact version plus a redacted openclaw status --all / relevant log excerpt: https://github.com/openclaw/openclaw/issues

Docs for the basic diagnostic flow: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/gateway/troubleshooting

[solemn vessel]

OpenClaw 2026.5.24-beta.2 (abb43c9)

[potent shore]

Thanks, that version is older than the lock fixes I found. 2026.5.24-beta.2 predates the #86427 fix that landed for 2026.5.26, and likely also misses some of the follow-up hardening around embedded session writes.

I’d update to current stable, restart the gateway, then retry the same Codex/pi-harness flow:

openclaw update
openclaw gateway restart
openclaw --version

If the error survives on 2026.5.26 or newer, file it as a fresh issue with that version and a redacted log excerpt: https://github.com/openclaw/openclaw/issues

[potent shore]

Summary:

The original error was:

EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released

I checked current OpenClaw source/changelog. There were recent fixes in this area, especially around embedded/pi-harness session locking:

• #84250: tolerate OpenClaw-owned transcript/session writes while embedded prompts are released for model I/O
• #86427: release embedded-attempt session locks on every exit path

The user was running:

[potent shore]

OpenClaw 2026.5.24-beta.2 (abb43c9)

That predates the later lock hardening in 2026.5.26, so the recommendation was: update to current stable, restart the gateway, then retry.

openclaw update
openclaw gateway restart
openclaw --version

If the same error still happens on 2026.5.26 or newer, it should be filed as a fresh GitHub issue with the exact version and a redacted log/status excerpt: https://github.com/openclaw/openclaw/issues

And yes: if that fixes it, please mark the solution so Answer Overflow indexes the fix for the next person.

[solemn vessel]

seeem i need a tag to do this upgrade

[potent shore]

Yep, if your updater wants an explicit tag, use the stable npm tag:

openclaw update --tag latest
openclaw gateway restart
openclaw --version

Equivalent channel form:

openclaw update --channel stable

If it still tries to stay on beta, pin the exact stable release:

[potent shore]

openclaw update --tag 2026.5.26

You can preview first with:

openclaw update --tag latest --dry-run

Docs: https://docs.openclaw.ai/cli/update

[solemn vessel]

openclaw update --tag latest --dry-run
│
◇
Update dry-run
No changes were applied.

Root: /home/lux/.npm-global/lib/node_modules/openclaw
Install kind: package
Mode: npm
Channel: stable
Tag/spec: openclaw@latest
Current version: 2026.5.24-beta.2
Target version: 2026.5.22
Downgrade confirmation would be required in a real run.

Planned actions:

• Run global package manager update with spec openclaw@latest
• Run plugin update sync after core update
• Refresh shell completion cache (if needed)
• Restart gateway service and run doctor checks

[potent shore]

Good catch. I need to correct my earlier wording: npm latest is currently resolving to 2026.5.22, so for you that would be a downgrade from 2026.5.24-beta.2.

Use the beta tag instead:

openclaw update --tag beta --dry-run
openclaw update --tag beta
openclaw gateway restart
openclaw --version

The currently published npm tags are:

latest -> 2026.5.22
beta   -> 2026.5.25-beta.1

[potent shore]

So the next useful package upgrade from your version is 2026.5.25-beta.1, not latest. If that still has the lock error, then it’s worth filing with the exact version because the source branch has more follow-up locking work than npm stable currently exposes.

[solemn vessel]

u mentioned a 26 version though

[potent shore]

You’re right. I mixed two things:

• 2026.5.26 is what current main source reports in package.json / changelog.
• npm does not currently have 2026.5.26 published as latest. The published tags I checked are:

latest -> 2026.5.22
beta   -> 2026.5.25-beta.1

So if you’re using the package install, don’t try latest right now. The practical upgrade path is:

openclaw update --tag beta

If you specifically need the unreleased 2026.5.26 source state, that would mean switching to the dev/main channel, but I’d only do that if you’re comfortable running from source:

[potent shore]

openclaw update --channel dev

Sorry for the confusion. The safer next step for your current install is --tag beta, then retest the error.

[solemn vessel]

Is the lock error fixed in that beta version?

[potent shore]

Yes, 2026.5.25-beta.1 includes the two relevant lock fixes I was referring to. I checked the published npm package, and its changelog contains:

• #84250: tolerate OpenClaw-owned transcript writes while embedded prompts are released, fixing false session-takeover errors
• #86427: release embedded-attempt session locks on every exit path, fixing later requests getting wedged behind SessionWriteLockTimeoutError

So this is the right package version to try:

openclaw update --tag beta
openclaw gateway restart
openclaw --version

I’d call it “expected fixed for the known false-positive cases,” not a guarantee that every possible lock/takeover case is gone. If you still hit the same error on 2026.5.25-beta.1, that’s useful signal and should go into a GitHub issue with the version + redacted logs: https://github.com/openclaw/openclaw/issues

[solemn vessel]

Update Result: OK
Root: /home/lux/.npm-global/lib/node_modules/openclaw
Before: 2026.5.24-beta.2
After: 2026.5.25-beta.1

Total time: 177.65s
│
◇

Updating plugins...
npm plugins: 0 updated, 1 unchanged.

Restarting service...
Gateway already reports the updated version after service refresh; skipped redundant restart.
Gateway: restarted and verified.

[potent shore]

Good, that’s the version with the relevant lock fixes. Please retry the original Codex/pi-harness flow now.

If it works, please mark the solution so Answer Overflow indexes it:

Right-click the solution message → Apps → ✅ Mark Solution

If the same EmbeddedAttemptSessionTakeoverError still appears on 2026.5.25-beta.1, grab a redacted openclaw status --all plus the nearby gateway log lines and file it here: https://github.com/openclaw/openclaw/issues

[desert sorrel]

did it work for @solemn vessel pi?

[solemn vessel]

12:45:59+00:00 warn fetch-timeout {"subsystem":"fetch-timeout"} {"timeoutMs":2500,"elapsedMs":2500,"operation":"fetchWithTimeout","url":"https://registry.npmjs.org/openclaw/latest"} fetch timeout reached; aborting operation

[potent shore]

That warning by itself doesn’t prove the Pi harness failed. It’s OpenClaw’s update check trying to fetch https://registry.npmjs.org/openclaw/latest and giving up after 2.5s, so I’d read it as “npm registry/network was slow or unreachable” unless there are follow-on errors.

Quick checks on the Pi:

openclaw --version
openclaw status
openclaw gateway status
npm view openclaw version

If npm view openclaw version also hangs/fails, it’s network/DNS/proxy/firewall from the Pi to npm rather than harness logic. If status is otherwise healthy, this warning is probably non-fatal/noisy.

Docs for the standard first-pass checks: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/gateway/troubleshooting

[solemn vessel]

||12:50:33+00:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=176473 error="EmbeddedAttemptSessionTakeoverError: LLM idle timeout (120s): no response from model"
||12:50:33+00:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:telegram:direct:||1275976396 ||durationMs=176481 error="EmbeddedAttemptSessionTakeoverError: LLM idle timeout (120s): no response from model"||||

[potent shore]

This means the harness did start a model request, but the model stream produced no chunks for 120s, so OpenClaw aborted it:

LLM idle timeout (120s): no response from model

That usually points at the configured model/provider being slow, wedged, overloaded, or not streaming correctly from the Pi, not the earlier npm update check.

Please grab the basics first:

openclaw --version
openclaw status --all
openclaw models status
openclaw logs --follow

If this is a slow local model / Pi-hosted model, try either a faster cloud model or raise the idle watchdog:

[potent shore]

openclaw config set agents.defaults.llm.idleTimeoutSeconds 300
openclaw gateway restart

Set it to 0 only if you intentionally want to disable the idle watchdog. Docs note the default/fallback behavior here: https://docs.openclaw.ai/concepts/agent-loop#timeouts

If models status shows auth/provider errors, fix that first; if it looks healthy but every run stalls, that’s worth a GitHub issue with the version + redacted status --all: https://github.com/openclaw/openclaw/issues

[solemn vessel]

Memory search provider is set to "openai" but no API key was found. │
│ Semantic recall will not work without a valid API key. │
│ │
│ │
│ Fix (pick one): │
│ - Set OPENAI_API_KEY in your environment │
│ - Configure credentials: openclaw configure --section model │
│ - To disable: openclaw config set agents.defaults.memorySearch.enabled fals

[potent shore]

That warning means memory search is explicitly trying to use OpenAI embeddings, but the gateway can’t resolve an OpenAI API key.

Pick the path you actually want:

• Use OpenAI embeddings: set OPENAI_API_KEY in the gateway environment, or run openclaw configure --section model, then restart/check the gateway.
• Use a different provider: set agents.defaults.memorySearch.provider to another supported provider like gemini, voyage, mistral, ollama, or local and configure that provider’s requirements.
• Disable semantic memory search: openclaw config set agents.defaults.memorySearch.enabled false

Note the last value is false; your pasted line is cut off as fals.

Docs: https://docs.openclaw.ai/reference/memory-config and https://docs.openclaw.ai/concepts/memory-search

If it still complains after that, first thing to paste is openclaw --version plus whether you’re running the gateway as a service or manually.

[solemn vessel]

21:16:00 [agents/tool-policy] tool policy removed 5 tool(s) via tools.profile (coding): agents_list, gateway, message, nodes, tts
│

[potent shore]

That log is usually informational: your config has tools.profile: "coding", and that profile intentionally keeps the agent focused on coding tools. It removes non-coding tools like message, gateway, nodes, tts, and agents_list.

If your agent is otherwise working, you can ignore it.

If you expected those tools to be available, change the tool profile/policy instead:

openclaw config set tools.profile full

Or keep coding and explicitly allow what you need, e.g. messaging/media/automation groups in config. Docs: https://docs.openclaw.ai/gateway/configuration-reference#tool-profiles

If this is part of a broken setup, please paste openclaw --version and the symptom after this line, not just the policy log.

[solemn vessel]

what are other options

[potent shore]

For tools.profile, the built-in options are:

• minimal - basically only session/status-level access
• coding - filesystem/runtime/web/sessions/memory plus cron and image/video generation; this is the local onboarding default
• messaging - message + session/history tools, for chat-focused agents
• full - no profile restriction

Examples:

openclaw config set tools.profile coding
openclaw config set tools.profile messaging
openclaw config set tools.profile full

You can also keep a profile and fine-tune with tools.allow / tools.deny. Deny wins, and if allow is set, everything not listed is blocked.

[potent shore]

Docs: https://docs.openclaw.ai/gateway/configuration-reference#tool-profiles

[solemn vessel]

Back to the memory part , what other options are there?

[potent shore]

For memory search providers, the main options are:

• openai - needs OPENAI_API_KEY
• gemini - needs GEMINI_API_KEY / Google provider auth
• voyage - needs VOYAGE_API_KEY
• mistral - needs MISTRAL_API_KEY
• github-copilot - uses a Copilot subscription/auth, no OpenAI API key
• bedrock - uses AWS credential chain, no API key in OpenClaw config
• ollama - local/self-hosted, must be set explicitly
• local - local embeddings, no API key, requires the local model/node-llama-cpp setup
• disabled - openclaw config set agents.defaults.memorySearch.enabled false

Examples:

openclaw config set agents.defaults.memorySearch.provider gemini

[potent shore]

openclaw config set agents.defaults.memorySearch.provider ollama
openclaw config set agents.defaults.memorySearch.provider local

If you don’t set a provider, OpenClaw auto-detects what it can use from configured credentials/local model availability. Docs: https://docs.openclaw.ai/reference/memory-config and https://docs.openclaw.ai/concepts/memory-search

[solemn vessel]

cant we ust use oauth

[potent shore]

For OpenAI/Codex OAuth: no, not for semantic memory search.

Codex OAuth covers chat/completions, but OpenAI embeddings still require real API access, so memory search with provider: "openai" needs OPENAI_API_KEY or models.providers.openai.apiKey.

OAuth-ish exception: github-copilot memory search can use Copilot auth/subscription, so that may work without an OpenAI API key if you have Copilot set up:

openclaw config set agents.defaults.memorySearch.provider github-copilot

Otherwise use a provider with an API key, use local/ollama, or disable semantic memory search.

Docs: https://docs.openclaw.ai/start/faq#does-semantic-memory-search-require-an-openai-api-key and https://docs.openclaw.ai/reference/memory-config

[solemn vessel]

whatt will local use

[potent shore]

local uses a GGUF embedding model on your machine through node-llama-cpp.

Default local model is:

embeddinggemma-300m-qat-Q8_0.gguf

It’s about 0.6 GB and is auto-downloaded unless you set your own agents.defaults.memorySearch.local.modelPath.

Config:

openclaw config set agents.defaults.memorySearch.provider local

If you installed from source and local embeddings fail to load, the docs call out the native build step:

[potent shore]

pnpm approve-builds
pnpm rebuild node-llama-cpp

You can tune/override:

• agents.defaults.memorySearch.local.modelPath - use a specific GGUF embedding model
• agents.defaults.memorySearch.local.modelCacheDir - where downloaded models are cached
• agents.defaults.memorySearch.local.contextSize - default is 4096; lower it on constrained machines

Docs: https://docs.openclaw.ai/reference/memory-config#local-embedding-config

[solemn vessel]

is it good

[potent shore]

It’s good enough for basic personal-memory recall, especially if you want no API key and local-only behavior.

Tradeoff: it probably won’t be as strong as hosted embeddings like OpenAI/Gemini/Voyage for fuzzy recall quality, but it’s cheap, private, and simple once node-llama-cpp is working. For normal MEMORY.md / notes search, I’d try local first if privacy/cost matters.

If recall feels weak, switch to openai, gemini, or voyage. If setup/build is annoying, ollama can also be a cleaner local route if you already run Ollama.

[solemn vessel]

Token auto-auth is disabled for SecretRef-managed gateway.auth.token; use your external token source if prompted.
Copied to clipboard.
Browser launch disabled (--no-open). Use the URL above.

[potent shore]

That message is expected when your gateway token is stored as a SecretRef.

It means openclaw dashboard deliberately did not put the token in the URL/clipboard/browser launch args. That’s safer: SecretRef-managed tokens are external secrets, so OpenClaw won’t copy the resolved secret around automatically.

What to do:

• Open the URL it printed.
• If the dashboard asks for auth, paste the real token from your external secret source into Control → Overview → Gateway Access → Gateway Token.
• If you want the CLI to bootstrap the dashboard for this shell, export the token first, then rerun:

export OPENCLAW_GATEWAY_TOKEN="your-token"
openclaw dashboard

• If you don’t know where the token comes from, inspect the config shape:

[potent shore]

openclaw config get gateway.auth.token

That should show which SecretRef source/provider/id is being used, not the secret itself.

Docs: https://docs.openclaw.ai/web/dashboard#auth-basics-local-vs-remote

[solemn vessel]

i want it auto

[potent shore]

If gateway.auth.token is SecretRef-managed, dashboard token auto-auth is intentionally disabled. There isn’t a “force auto-auth SecretRef token into URL” switch, because that would leak the external secret into clipboard/browser args/shell logs.

Your options:

1. Keep SecretRef, paste manually when prompted. Most secure.
2. Stop using SecretRef for the gateway token and store a normal token in config. Then openclaw dashboard can include #token=... automatically.
3. Use an identity auth path instead of token pasting, e.g. Tailscale Serve with gateway.auth.allowTailscale: true, or gateway.auth.mode: "trusted-proxy" behind an identity-aware proxy.
4. If you just want the browser to open, don’t pass --no-open:

openclaw dashboard

But with SecretRef it will still open a non-tokenized URL.

I’d only switch away from SecretRef if this is a local/dev box and convenience matters more than keeping the gateway token out of clipboard/history. Don’t paste the actual token here.

[solemn vessel]

where is token

[potent shore]

Check what OpenClaw is configured to use:

openclaw config get gateway.auth.token

If it prints a plain string, that is the token. Don’t paste it here.

If it prints something like a SecretRef object, for example { source: "env", ... id: "OPENCLAW_GATEWAY_TOKEN" }, then the token is not stored directly in OpenClaw config. It lives in that external source:

• source: "env" / id: "OPENCLAW_GATEWAY_TOKEN" → check your shell/service env:

  echo "$OPENCLAW_GATEWAY_TOKEN"
  

• source: "file" → check the configured file under secrets.providers...
• source: "exec" → it comes from the configured secret-resolver command

[potent shore]

You can also run:

openclaw status --all

It should summarize auth/config without exposing the secret. Docs: https://docs.openclaw.ai/web/dashboard#auth-basics-local-vs-remote

[willow jewel]

Ich habe seit einiger zeit das andere Problem das ich die Pi runtime mit meinem Chatgpt Codex oAuth nutzen möchte , der doctor aber immer weider in openai mit codex runtime "repariert". - Gibt es hierzu mittlerweile eine Lösung in diesem Thread? kannst du den Zusammenfassen

[potent shore]

Kurzfassung: In diesem Thread selbst gab es dazu noch keine fertige Lösung; bisher ging es um Memory Search und Dashboard-Token. Aber die aktuelle Doku unterscheidet genau zwei Codex-Routen, und da liegt vermutlich die Verwechslung:

• PI Runtime + ChatGPT/Codex OAuth: Modell muss openai-codex/... sein, z.B.

  openclaw models auth login --provider openai-codex
  openclaw config set agents.defaults.model.primary openai-codex/gpt-5.5
  openclaw config set agents.defaults.embeddedHarness.runtime pi
  

• Native Codex/App-Server Runtime: Modell bleibt openai/..., aber Harness wird codex:

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

[potent shore]

      }
    }
  }

Wenn du PI mit Codex OAuth willst, dann ist openai/gpt-5.5 + embeddedHarness.runtime: "codex" gerade die falsche Route. Dafür ist openai-codex/gpt-5.5 der explizite PI/OAuth-Pfad.

Wichtig: bestehende Sessions behalten ihren gepinnten Harness. Nach der Änderung also eine neue Session starten oder resetten, sonst sieht es so aus, als ob die Config ignoriert wird.

Wenn Doctor das immer wieder “repariert”, bitte zuerst posten:

openclaw --version
openclaw config get agents.defaults.model
openclaw config get agents.defaults.embeddedHarness
openclaw config get models.providers.openai-codex

[potent shore]

Keine Tokens posten. Besonders models.providers.openai-codex ist relevant, weil alte Provider-Overrides den eingebauten Codex-OAuth-Pfad shadowen können.

Docs: https://docs.openclaw.ai/providers/openai und https://docs.openclaw.ai/gateway/configuration-reference#agentsdefaultsembeddedharness

[willow jewel]

daniel@Mac-Mini ~ % openclaw --version
openclaw config get agents.defaults.model
openclaw config get agents.defaults.embeddedHarness
openclaw config get models.providers.openai-codex
OpenClaw 2026.5.27 (27ae826)

🦞 OpenClaw 2026.5.27 (27ae826) — Greetings, Professor Falken

{
"primary": "openai-codex/gpt-5.4",
"fallbacks": [
"openai-codex/gpt-5.4-mini"
]
}

Config path not found: agents.defaults.embeddedHarness. Run openclaw config validate to inspect config shape.

Config path not found: models.providers.openai-codex. Run openclaw config validate to inspect config shape.

[potent shore]

Das sieht erstmal nicht kaputt aus. Deine aktuelle Config ist schon auf der PI/Codex-OAuth-Route:

{
  "primary": "openai-codex/gpt-5.4",
  "fallbacks": ["openai-codex/gpt-5.4-mini"]
}

Wichtig dabei:

• openai-codex/... = Codex OAuth über die PI-Route
• agents.defaults.embeddedHarness fehlt = kein expliziter Codex-Harness erzwungen
• models.providers.openai-codex fehlt = gut/neutral; da liegt also kein alter Provider-Override, der den eingebauten Codex-OAuth-Pfad shadowt

Wenn du PI wirklich festnageln willst, kannst du optional setzen:

[potent shore]

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

Danach neue Session starten/resetten, weil Harness-Auswahl pro Session gepinnt wird.

Wenn Doctor trotzdem auf openai/... “repariert”, brauche ich die konkrete Doctor-Zeile:

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

Nicht Tokens posten. Aber anhand der Ausgabe hier: aktuell bist du nicht auf der nativen Codex-App-Server-Route, sondern auf openai-codex, also der richtigen Richtung für PI + Codex OAuth.

[willow jewel]

Kannst du das nochmal prüfen. Doctor will ja immer openai-codex repariern , weil legacy du schriebst es wäre der richtige weg

PI Runtime + ChatGPT/Codex OAuth: Modell muss openai-codex/... sein, z.B.
openclaw models auth login --provider openai-codex
openclaw config set agents.defaults.model.primary openai-codex/gpt-5.5
openclaw config set agents.defaults.embeddedHarness.runtime pi

[potent shore]

Ja, guter Catch. Die präzise Unterscheidung ist:

• openai-codex/... als Modellname ist nicht legacy. Das ist laut aktueller Doku weiterhin der richtige Weg für PI Runtime + ChatGPT/Codex OAuth.
• models.providers.openai-codex als Provider-Override kann legacy sein, wenn dort alte Transport-Felder wie api: "openai-responses", api: "openai-completions" oder baseUrl: "https://api.openai.com/v1" stehen. Genau das meint Doctor mit “legacy/shadowing”.

In deiner Ausgabe war:

agents.defaults.model.primary = openai-codex/gpt-5.4
models.providers.openai-codex = Config path not found

Das heißt: Dein Model-Ref ist auf der richtigen Codex-OAuth/PI-Schiene, und der konkrete legacy-Provider-Override war in dieser Ausgabe nicht vorhanden.

Ich würde meine vorherige Empfehlung leicht korrigieren: embeddedHarness.runtime: pi ist optional und wahrscheinlich nicht nötig. Wenn du es setzen willst, dann besser als ganzes Objekt:

[potent shore]

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

Aber der wichtigere Punkt ist: Wenn Doctor weiterhin “legacy openai-codex” meldet, bitte die exakte Doctor-Warnung posten. Es gibt zwei verschiedene Fälle:

• Warnung über models.providers.openai-codex → alten Provider-Override entfernen/umschreiben.
• Migration “Marked models.providers.openai-codex.models.gpt-5.5 as /models add metadata…” → das ist eine Metadaten-Reparatur, nicht “openai-codex ist falsch”.

Kurz: openai-codex/gpt-5.4 oder openai-codex/gpt-5.5 ist für PI + OAuth richtig. Legacy ist nur der alte models.providers.openai-codex-Override/Transport-Kram.

[potent shore]

Brief thread summary:

Initial issue: memory search was configured with provider: "openai", but no OpenAI API key was available. Codex/OpenAI OAuth does not cover embeddings, so OpenAI memory search needs OPENAI_API_KEY or models.providers.openai.apiKey.

Options discussed:

• Set OPENAI_API_KEY / run openclaw configure --section model
• Switch memory search to another provider: gemini, voyage, mistral, github-copilot, bedrock, ollama, or local
• Use local memory search:

  openclaw config set agents.defaults.memorySearch.provider local
  

  Local uses embeddinggemma-300m-qat-Q8_0.gguf by default, about 0.6 GB, via node-llama-cpp.
• Disable semantic memory search:

  openclaw config set agents.defaults.memorySearch.enabled false
  

[potent shore]

Other topics that came up:

• tools.profile: "coding" removing message, gateway, nodes, etc. is expected; use minimal, coding, messaging, or full depending on desired tool access.
• SecretRef-managed gateway.auth.token intentionally does not auto-inject the token into dashboard URLs. Paste the external token manually, use env/plain config for convenience, or use an identity auth path like Tailscale/trusted proxy.
• For PI runtime + ChatGPT/Codex OAuth, openai-codex/... as the model ref is correct. What Doctor calls legacy is usually old models.providers.openai-codex transport/provider override config, not the openai-codex/... model ref itself.

If the memory-search issue is solved, please mark the solution so Answer Overflow indexes it, then start fresh threads for the dashboard/tool-profile/Codex-runtime topics.

[potent shore]

Brief summary:

Original issue: memory search was set to use OpenAI embeddings, but no OpenAI API key was available. Codex/OpenAI OAuth does not cover embeddings, so OpenAI memory search needs OPENAI_API_KEY or models.providers.openai.apiKey.

Fix options:

• Add an OpenAI API key / run:

  openclaw configure --section model
  

• Switch memory search to another provider: gemini, voyage, mistral, github-copilot, bedrock, ollama, or local
• Use local embeddings:

  openclaw config set agents.defaults.memorySearch.provider local
  

  Local uses embeddinggemma-300m-qat-Q8_0.gguf by default, about 0.6 GB, via node-llama-cpp.
• Disable semantic memory search:

[potent shore]

  openclaw config set agents.defaults.memorySearch.enabled false

Other separate topics discussed:

• tools.profile: "coding" removing tools like message, gateway, nodes, and tts is expected. Profiles include minimal, coding, messaging, and full.
• SecretRef-managed gateway.auth.token intentionally does not auto-inject into dashboard URLs. Paste the external token manually, use env/plain config for convenience, or use Tailscale/trusted-proxy auth.
• For PI runtime + ChatGPT/Codex OAuth, openai-codex/... as the model ref is correct. Doctor’s “legacy” warning usually refers to old models.providers.openai-codex transport/provider override config, not the openai-codex/... model ref itself.

If the memory-search issue is solved, please mark the solution and start new threads for the dashboard/tool-profile/Codex-runtime topics so Answer Overflow stays useful.

[solemn vessel]

how to add models easily to openclaw

[potent shore]

Best/easiest paths:

1. Interactive setup for a provider:

openclaw configure --section model

2. See what OpenClaw already knows about:

openclaw models list
openclaw models status

3. Switch default model:

openclaw models set provider/model

[potent shore]

4. Add a model to the allowlist/config safely:

openclaw config set agents.defaults.models '{"provider/model":{}}' --strict-json --merge

5. From chat, if enabled, the quickest path is:

/models add
/models add <provider> <model-id>
/model <provider/model>

After /models add, it should show up in /models and /model without restarting the gateway.

For auth:

openclaw models auth add