What does work via openai codex subscription what needs paygo billing?

[sinful mesa]

I'm on the new 5.12 version, maybe I'm trying to hunt down some ghosts here... 😅
What should be possible in OpenClaw using my codex subscription?
I mean I saw of course that the agentic flow works...
so basically chat works. But what about text to speech, speech to text, real time voice, image creation and web search?
Which of these things should work using the subscription

[wary lodge]

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

[vestal kayak]

Short version: the Codex subscription mainly covers OpenAI/Codex agent turns. Other OpenAI product APIs are mostly separate Platform/API-key surfaces, except image generation now has explicit Codex OAuth support in the OpenClaw docs.

For 5.12-ish/current docs, I’d bucket it like this:

• Chat / agentic flow: yes via Codex auth. Use the canonical OpenAI route like openai/...; old openai-codex/... refs are legacy/doctor-repaired.
• Image creation/editing: yes, OpenClaw docs say openai/gpt-image-2 works with either OPENAI_API_KEY or OpenAI Codex OAuth. Transparent-background images use openai/gpt-image-1.5.
• Text-to-speech: OpenAI TTS expects OPENAI_API_KEY, so treat that as pay-as-you-go Platform billing. There are other providers too, including Microsoft as a best-effort key-free option.
• Speech-to-text / voice-note transcription: OpenAI STT is an OpenAI API/provider auth path, so treat it as Platform/API-key unless you’re using local CLI fallback or another provider.
• Realtime voice: OpenAI realtime/Talk config wants an OpenAI API key, so pay-as-you-go. Also needs the Talk/voice stack configured separately.
• Web search: two paths. Managed web_search uses whichever search provider you configure, many need separate keys but DuckDuckGo/SearXNG can be key-free. Native Codex web search can be enabled for Codex-capable models under tools.web.search.openaiCodex, so that’s the Codex-side path.

Docs:
https://docs.openclaw.ai/providers/openai
https://docs.openclaw.ai/tools/image-generation
https://docs.openclaw.ai/tools/tts
https://docs.openclaw.ai/tools/web
https://docs.openclaw.ai/tools/media-overview

[vestal kayak]

So if something “works in chat but not in speech/realtime/TTS”, that’s not necessarily broken; it may just need a real OpenAI Platform key or another configured media provider.

[sinful mesa]

okay so how much does real time voice cost via api?
I forgot to ask about vision, so if I send an image?

also does web search really work via the subscription? because the docs say:

It only activates for Codex-capable models (openai-codex/* or providers using api: "openai-codex-responses")

how can i test that it uses my subscription and not the api key / the normal searches? how to trace / check that?

[vestal kayak]

For realtime voice API cost: use OpenAI’s live pricing page as source of truth, because it changes. Current docs show Realtime voice billed by tokens, not a flat “conversation minute” price:

• GPT-Realtime audio: $32 / 1M audio input tokens, $0.40 / 1M cached audio input tokens, $64 / 1M audio output tokens.
• Realtime transcription-only is listed separately at about $0.017/min for the streaming whisper realtime transcription model.
• Normal speech-to-text uploads are cheaper: docs currently estimate about $0.003/min mini or $0.006/min higher accuracy.

So full realtime voice cost depends on how much audio goes in/out, silence/VAD, interruptions, and whether it’s doing text/tool consults too. It is API/paygo, not Codex subscription. Pricing: https://platform.openai.com/docs/pricing

Vision/images you send in chat: if the active reply model/runtime supports image input, OpenClaw can pass the image into the agent turn. With Codex-auth agent turns, that should be part of the Codex/subscription-backed agent path, not image-generation API billing. Separate thing: generating/editing images with image_generate is its own OpenAI image surface; OpenClaw docs say that can use either OPENAI_API_KEY or OpenAI Codex OAuth.

For native Codex web search: yes, but only when all of these are true:
• tools.web.search.enabled !== false
• tools.web.search.openaiCodex.enabled: true
• current model is Codex-capable internally: provider openai-codex or provider API openai-codex-responses
• Codex OAuth auth exists when using the openai-codex provider path

When native Codex search is active, OpenClaw suppresses the managed web_search tool and injects provider-native web_search into the OpenAI/Codex payload. That’s the important test signal.

[vestal kayak]

How I’d trace it:

1. Enable it:

openclaw configure --section web

Choose native Codex web search, cached mode, and skip managed provider if you want a clean test.

2. Turn on debug logging temporarily, reproduce one search query, then tail logs:

openclaw config set logging.level debug
openclaw gateway restart
openclaw logs --follow

3. Look for one of these log lines:

[vestal kayak]

activating Codex native web search (cached) for ...
Injected Codex native web search tool into provider payload

If instead you see:

skipping Codex native web search (model_not_eligible|codex_not_enabled|codex_auth_missing)
web_search: no provider configured, auto-detected ...

then it is not using native Codex search; it’s falling back to managed search or no managed provider.

Docs:
https://docs.openclaw.ai/tools/web
https://docs.openclaw.ai/providers/openai
https://docs.openclaw.ai/nodes/audio
https://docs.openclaw.ai/nodes/talk

[sinful mesa]

The issue I had was that I saw in my agent turns, so in the responses or something, that it had used Gemini Flash two point five. But the strange strange thing is I don't see any Gemini key or something configured. I don't know how it could possibly use that. Maybe via open router, but even then there was nothing configured to make it use Gemini.

[vestal kayak]

That’s a good clue. It usually means one of these, not necessarily a literal GEMINI_API_KEY in your visible config:

• It was actually an OpenRouter model, e.g. openrouter/google/gemini-.... In UI/logs this can look like “Gemini Flash” even though auth is OpenRouter.
• It came from a fallback list: agents.defaults.model.fallbacks, an agent-specific fallback, imageModel, pdfModel, or a media-understanding fallback.
• It used Gemini CLI OAuth / Google auth profile, not an API key. Docs mention google-gemini-cli profiles separately from GEMINI_API_KEY.
• The key/env exists on the gateway host, not your current shell. OpenClaw can load env from the gateway service env, shell import, ~/.openclaw/.env, auth profiles, or models.providers.*.

I’d trace it like this:

openclaw --version
openclaw models status --probe
openclaw config get agents.defaults.model
openclaw config get agents.defaults.imageModel
openclaw config get agents.defaults.pdfModel
openclaw config get agents.defaults.models

[vestal kayak]

openclaw config get models.providers
openclaw config get auth.order

Also check whether there are auth profiles for Google/OpenRouter:

openclaw models auth order get --provider google
openclaw models auth order get --provider google-gemini-cli
openclaw models auth order get --provider openrouter

If this is happening only when you send an image, pay special attention to agents.defaults.imageModel and tools.media.image/audio/video style settings. Image input can route through image/media understanding, which may use a different model than the normal chat model.

The fastest smoking gun is usually in the agent run metadata/log line: look for the full provider/model, not the friendly model name. These are very different:

[vestal kayak]

google/gemini-...
google-gemini-cli/gemini-...
openrouter/google/gemini-...

If it says openrouter/google/..., Gemini is just the upstream model inside OpenRouter. If it says google-gemini-cli/..., it is CLI OAuth. If it says google/..., then either Google API key/auth profile/env exists somewhere the gateway can see, or fallback config is trying Google and should show up in models status --probe.

Docs:
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/cli/models
https://docs.openclaw.ai/gateway/authentication

[sinful mesa]

I tested the debug things:

19:50:02+00:00 info plugins {"subsystem":"plugins"} memory-lancedb: injecting 2 memories into context
19:50:03+00:00 debug agent/embedded {"subsystem":"agent/embedded"} codex app-server stderr: 2026-05-15T19:50:03.549326Z ERROR codex_app_server: Project-local config, hooks, and exec policies are disabled in the following folders until the project is trusted, but skills still load.
1. /home/hakalya/.codex
To load project-local config, hooks, and exec policies, add /home/hakalya as a trusted project in /home/hakalya/.openclaw/agents/main/agent/codex-home/config.toml.

Dann hab ich eine frage an den agenten gestellt bei der er web search benutzen musste:
Ich schick dir das in mehreren teilen und sage dir wenn ich fertig bin mit "###FERTIG###"

[vestal kayak]

Yep, send the parts. I’ll wait for ###FERTIG### before analyzing so we don’t chase half a trace.

That log line is probably separate from web search: Codex is saying project-local config/hooks/exec policies under /home/hakalya/.codex are disabled until trusted. Annoying, but not by itself proof that search used Gemini/OpenRouter/API billing. The useful lines will be the ones around Codex native web search, web_search:, provider/model selection, or tool payload injection.

[sinful mesa]

19:55:25+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ health 52ms cached=true conn=9d41520e…82cc id=afb45ee3…7b9d
19:55:40+00:00 debug gateway/channels/telegram/raw-update {"subsystem":"gateway/channels/telegram/raw-update"} telegram update: {"update_id":549925782,"message":{"message_id":20635,"from":{"id":258054267,"is_bot":false,"first_name":"Horo","username":"HoroTW","language_code":"en"},"chat":{"id":-5121672411,"title":"Hakalya Management","type":"group","all_members_are_administrators":false,"accepted_gift_types":{"unlimited_gifts":false,"limited_gifts":false,"unique_gifts":false,"premium_subscription":false,"gifts_from_channels":false}},"date":1778874940,"text":"okay, gibt es in google play eine offizielle neue version?"}}
19:55:40+00:00 debug [routing] resolveAgentRoute: channel=telegram accountId=default peer=group:-5121672411 guildId=none teamId=none bindings=1
19:55:40+00:00 debug [routing] binding: agentId=friends-gpt55 accountPattern=default peer=group:-1003960682484 guildId=none teamId=none roles=0
19:55:40+00:00 debug [routing] resolveAgentRoute: channel=telegram accountId=default peer=group:-5121672411 guildId=none teamId=none bindings=1
19:55:40+00:00 debug [routing] binding: agentId=friends-gpt55 accountPattern=default peer=group:-1003960682484 guildId=none teamId=none roles=0
19:55:43+00:00 debug [routing] resolveAgentRoute: channel=telegram accountId=default peer=group:-5121672411 guildId=none teamId=none bindings=1
19:55:43+00:00 debug [routing] binding: agentId=friends-gpt55 accountPattern=default peer=group:-1003960682484 guildId=none teamId=none roles=0
19:55:43+00:00 debug {"message":"telegram inbound: chatId=-5121672411 from=telegram:group:-5121672411 len=153 preview="[Telegram Hakalya Management id:-5121672411 +53m Fri 2026-05-15 21:55 GMT+2] Horo (258054267): okay, gibt es in google play eine offizielle neue version?""} verbose

19:55:43+00:00 debug {"message":"telegram ingress: chatId=-5121672411 contextReadyMs=3045 preDispatchMs=38 buffer=inbound-debounce"} verbose
19:55:43+00:00 info gateway/channels/telegram/inbound {"subsystem":"gateway/channels/telegram/inbound"} Inbound message telegram:group:-5121672411 -> @Hakalyabot (group, 58 chars)
19:55:43+00:00 debug {"message":"telegram stream preview ready (maxChars=4000, throttleMs=1000)"} verbose
19:55:43+00:00 debug diagnostic {"subsystem":"diagnostic"} message queued: sessionId=unknown sessionKey=agent:main:telegram:group:-5121672411 source=dispatch queueDepth=1 sessionState=idle
19:55:43+00:00 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=unknown sessionKey=agent:main:telegram:group:-5121672411 prev=idle new=processing reason="message_start" queueDepth=1
19:55:43+00:00 debug {"message":"Delivery suppressed by sourceReplyDeliveryMode: message_tool_only for session agent:main:telegram:group:-5121672411 — agent will still process the message"} verbose
19:55:43+00:00 warn plugins {"subsystem":"plugins"} device-pair: notify poll failed: Failed to read JSON file: /home/hakalya/.openclaw/devices/paired.json | File changed during read: /home/hakalya/.openclaw/devices/paired.json
19:55:43+00:00 debug agents/auth-profiles {"subsystem":"agents/auth-profiles"} {"profileId":"anthropic:claude-cli","provider":"claude-cli","localExpires":1777814976121,"externalExpires":1777814976121} kept usable local oauth over external cli bootstrap
19:55:44+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading anthropic from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/anthropic/index.js
19:55:44+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading arcee from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/arcee/index.js

19:55:44+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading byteplus from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/byteplus/index.js
19:55:44+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading cerebras from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/cerebras/index.js
19:55:44+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading chutes from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/chutes/index.js
19:55:44+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading cloudflare-ai-gateway from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/cloudflare-ai-gateway/index.js
19:55:44+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading comfy from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/comfy/index.js
19:55:44+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading copilot-proxy from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/copilot-proxy/index.js
19:55:44+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading deepinfra from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/deepinfra/index.js
19:55:44+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading deepseek from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/deepseek/index.js
19:55:44+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading fal from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/fal/index.js
19:55:44+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading fireworks from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/fireworks/index.js
....

19:55:45+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading codex from /home/hakalya/.openclaw/npm/node_modules/@openclaw/codex/dist/index.js
19:55:45+00:00 debug plugins {"subsystem":"plugins"} [plugins] loaded 46 plugin(s) (46 attempted) in 519.0ms
19:55:45+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading cerebras from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/cerebras/index.js
19:55:45+00:00 debug plugins {"subsystem":"plugins"} [plugins] loaded 1 plugin(s) (1 attempted) in 2.3ms
19:55:46+00:00 debug agents/auth-profiles {"subsystem":"agents/auth-profiles"} {"profileId":"anthropic:claude-cli","provider":"claude-cli","localExpires":1777814976121,"externalExpires":1777814976121} kept usable local oauth over external cli bootstrap
19:55:47+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading deepinfra from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/deepinfra/index.js
19:55:47+00:00 debug plugins {"subsystem":"plugins"} [plugins] loaded 1 plugin(s) (1 attempted) in 2.4ms
19:55:47+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading deepseek from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/deepseek/index.js
19:55:47+00:00 debug plugins {"subsystem":"plugins"} [plugins] loaded 1 plugin(s) (1 attempted) in 4.2ms

....
19:56:08+00:00 debug agents/auth-profiles {"subsystem":"agents/auth-profiles"} {"profileId":"anthropic:claude-cli","provider":"claude-cli","localExpires":1777814976121,"externalExpires":1777814976121} kept usable local oauth over external cli bootstrap
19:56:08+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading codex from /home/hakalya/.openclaw/npm/node_modules/@openclaw/codex/dist/index.js
19:56:09+00:00 debug plugins {"subsystem":"plugins"} [plugins] loaded 1 plugin(s) (1 attempted) in 112.1ms
19:56:09+00:00 warn diagnostic {"subsystem":"diagnostic"} liveness warning: reasons=event_loop_delay interval=51s eventLoopDelayP99Ms=107.8 eventLoopDelayMaxMs=24981.3 eventLoopUtilization=0.563 cpuCoreRatio=0.604 active=1 waiting=0 queued=1 phase=channels.telegram.start-account recentPhases=sidecars.main-session-recovery:4ms,sidecars.restart-sentinel:22ms,post-attach.update-sentinel:10ms,post-ready.maintenance:66ms,sidecars.session-locks:1843ms,sidecars.model-prewarm:2285ms work=[active=agent:main:telegram:group:-5121672411(processing,q=1,age=26s) queued=agent:main:telegram:group:-5121672411(processing,q=1,age=26s)]
19:56:09+00:00 debug diagnostic {"subsystem":"diagnostic"} heartbeat: webhooks=0/0/0 active=1 waiting=0 queued=1
19:56:09+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ health 51ms cached=true conn=9d41520e…82cc id=d78de393…1386

19:56:09+00:00 debug cron {"module":"cron","storePath":"/home/hakalya/.openclaw/cron/jobs.json"} {"nextAt":1778889600000,"delayMs":60000,"clamped":true} cron: timer armed
19:56:09+00:00 debug agent/embedded {"subsystem":"agent/embedded"} codex app-server stderr: 2026-05-15T19:56:09.888724Z ERROR codex_app_server: Project-local config, hooks, and exec policies are disabled in the following folders until the project is trusted, but skills still load.
1. /home/hakalya/.codex
To load project-local config, hooks, and exec policies, add /home/hakalya as a trusted project in /home/hakalya/.openclaw/agents/main/agent/codex-home/config.toml.
19:56:12+00:00 debug agents/auth-profiles {"subsystem":"agents/auth-profiles"} {"profileId":"anthropic:claude-cli","provider":"claude-cli","localExpires":1777814976121,"externalExpires":1777814976121} kept usable local oauth over external cli bootstrap
19:56:13+00:00 debug agents/auth-profiles {"subsystem":"agents/auth-profiles"} {"profileId":"anthropic:claude-cli","provider":"claude-cli","localExpires":1777814976121,"externalExpires":1777814976121} kept usable local oauth over external cli bootstrap
19:56:14+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading lmstudio from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/lmstudio/index.js

19:56:19+00:00 debug agents/auth-profiles {"subsystem":"agents/auth-profiles"} {"profileId":"anthropic:claude-cli","provider":"claude-cli","localExpires":1777814976121,"externalExpires":1777814976121} kept usable local oauth over external cli bootstrap
19:56:20+00:00 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:main:telegram:group:-5121672411 queueSize=1
19:56:20+00:00 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:main:telegram:group:-5121672411 waitMs=2 queueSize=0
19:56:20+00:00 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=main queueSize=1
19:56:20+00:00 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=main waitMs=2 queueSize=0
19:56:20+00:00 debug agents/harness {"subsystem":"agents/harness"} {"provider":"openai","modelId":"gpt-5.5","sessionKey":"agent:main:telegram:group:-5121672411","agentId":"main","selectedHarnessId":"codex","selectedReason":"forced_plugin","runtime":"codex","candidates":[{"id":"codex","label":"Codex agent harness","pluginId":"codex"}]} agent harness selected
19:56:20+00:00 warn plugins {"subsystem":"plugins"} device-pair: notify poll failed: Failed to read JSON file: /home/hakalya/.openclaw/devices/paired.json | File changed during read: /home/hakalya/.openclaw/devices/paired.json
19:56:21+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading browser from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/browser/index.js

19:56:21+00:00 debug plugins {"subsystem":"plugins"} [plugins] loaded 10 plugin(s) (5 attempted) in 20.7ms
19:56:21+00:00 debug plugins {"subsystem":"plugins"} [hooks] running before_prompt_build (1 handlers, sequential)
19:56:22+00:00 info plugins {"subsystem":"plugins"} memory-lancedb: injecting 2 memories into context
19:56:23+00:00 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=d1ce3386-2502-4a3b-8195-706d6ef9b714 sessionKey=agent:main:telegram:group:-5121672411 prev=processing new=processing reason="run_started" queueDepth=1
19:56:23+00:00 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=d1ce3386-2502-4a3b-8195-706d6ef9b714 totalActive=1
19:56:29+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ message.action 203ms channel=telegram conn=204edcb8…3242 id=9f264dcb…b26a
19:56:33+00:00 debug plugins {"subsystem":"plugins"} [plugins] loading firecrawl from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/firecrawl/index.js
19:56:33+00:00 debug plugins {"subsystem":"plugins"} [plugins] loaded 1 plugin(s) (1 attempted) in 2.9ms
19:56:37+00:00 info browser/chrome {"subsystem":"browser/chrome"} 🦞 openclaw browser started (chromium) profile "openclaw" on 127.0.0.1:18800 (pid 1770998)
19:56:39+00:00 debug diagnostic {"subsystem":"diagnostic"} heartbeat: webhooks=0/0/0 active=1 waiting=0 queued=1

19:56:39+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 59ms conn=ee71f5b9…36f8 id=2d5647ea…6462
19:56:58+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ message.action 159ms channel=telegram conn=26bbd82a…47f9 id=8decadf5…a8f9
19:57:01+00:00 debug plugins {"subsystem":"plugins"} [hooks] running agent_end (1 handlers)
19:57:01+00:00 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=d1ce3386-2502-4a3b-8195-706d6ef9b714 sessionKey=agent:main:telegram:group:-5121672411 prev=processing new=idle reason="run_completed" queueDepth=0
19:57:01+00:00 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=d1ce3386-2502-4a3b-8195-706d6ef9b714 totalActive=0
19:57:01+00:00 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=cccf64bf-6d53-47d7-9c6f-cadddc2f9aea sessionId=d1ce3386-2502-4a3b-8195-706d6ef9b714 durationMs=40844 aborted=false
19:57:01+00:00 debug agents/auth-profiles {"subsystem":"agents/auth-profiles"} {"profileId":"anthropic:claude-cli","provider":"claude-cli","localExpires":1777814976121,"externalExpires":1777814976121} kept usable local oauth over external cli bootstrap

19:57:02+00:00 debug agents/auth-profiles {"subsystem":"agents/auth-profiles"} {"profileId":"anthropic:claude-cli","provider":"claude-cli","localExpires":1777814976121,"externalExpires":1777814976121} kept usable local oauth over external cli bootstrap
19:57:02+00:00 debug agents/auth-profiles {"subsystem":"agents/auth-profiles"} {"profileId":"anthropic:claude-cli","provider":"claude-cli","localExpires":1777814976121,"externalExpires":1777814976121} kept usable local oauth over external cli bootstrap
19:57:02+00:00 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=42185 active=0 queued=0
19:57:02+00:00 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:telegram:group:-5121672411 durationMs=42192 active=0 queued=0
19:57:02+00:00 debug diagnostic {"subsystem":"diagnostic"} message processed: channel=telegram chatId=telegram:-5121672411 messageId=20635 sessionId=unknown sessionKey=agent:main:telegram:group:-5121672411 outcome=completed duration=79386ms
19:57:02+00:00 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=d1ce3386-2502-4a3b-8195-706d6ef9b714 sessionKey=agent:main:telegram:group:-5121672411 prev=idle new=idle reason="message_completed" queueDepth=0

###FERTIG###

[vestal kayak]

From this trace, I don’t see Gemini/OpenRouter being used at all.

The important line is:

agents/harness ... {"provider":"openai","modelId":"gpt-5.5", ... "selectedHarnessId":"codex","selectedReason":"forced_plugin","runtime":"codex"} agent harness selected

So this run selected openai/gpt-5.5 through the Codex harness. That points to the subscription/Codex path for the agent turn.

What I also don’t see:
• no activating Codex native web search
• no Injected Codex native web search tool into provider payload
• no web_search: no provider configured...
• no google/gemini..., google-gemini-cli/..., or openrouter/google/...

What I do see instead:

[vestal kayak]

• firecrawl plugin loaded
• browser/chrome ... openclaw browser started

Plugin loading alone does not mean it was used, but the browser start is a strong hint the agent may have used browser automation / page lookup instead of web_search. For “is there an official new version in Google Play?”, Codex might decide to open/search the web via browser rather than call the native Responses web search tool.

To make the next trace decisive, grep the full log for just this run window:

openclaw logs --since 2026-05-15T19:55:30Z | rg -i "agent harness selected|codex native|web_search|web search|browser/chrome|browser action|firecrawl|web_fetch|openrouter|gemini|google|provider payload|tool"

If native Codex search is working, I’d expect one of these:

activating Codex native web search (cached) for ...
Injected Codex native web search tool into provider payload

[vestal kayak]

If managed search is being used:

web_search: no provider configured, auto-detected ...
web_search provider ...

If browser is being used:

browser/chrome ...
browser action / navigate / snapshot / screenshot ...

For forcing a cleaner web-search test, temporarily disable browser and managed fetch/search providers, then ask something current:

openclaw config set tools.web.search.openaiCodex.enabled true

[vestal kayak]

openclaw config set tools.web.search.openaiCodex.mode cached
openclaw config set browser.enabled false
openclaw gateway restart

Then ask the same kind of current-info question and check for the Codex native web search log lines. Re-enable browser afterwards if you use it.

[sinful mesa]

openclaw logs | rg -i "agent harness selected|codex native|web_search|web search|browser/chrome|browser action|firecrawl|web_fetch|openrouter|gemini|google|provider payload|tool"
2026-05-15T20:32:01.005Z debug plugins {"subsystem":"plugins"} [plugins] loading openrouter from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/openrouter/index.js
2026-05-15T20:32:34.804Z debug plugins {"subsystem":"plugins"} [plugins] loading google from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/google/index.js
2026-05-15T20:32:34.839Z debug plugins {"subsystem":"plugins"} [plugins] loading openrouter from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/openrouter/index.js
2026-05-15T20:32:36.096Z debug agents/harness {"subsystem":"agents/harness"} {"provider":"openai","modelId":"gpt-5.5","sessionKey":"agent:main:main","agentId":"main","selectedHarnessId":"codex","selectedReason":"forced_plugin","runtime":"codex","candidates":[{"id":"codex","label":"Codex agent harness","pluginId":"codex"}]} agent harness selected
2026-05-15T20:32:39.439Z debug agent/embedded {"subsystem":"agent/embedded"} {"threadId":"019e2d30-6177-7b02-963f-979065a87205"} codex app-server dynamic tool catalog changed; starting a new thread
2026-05-15T20:32:48.393Z debug plugins {"subsystem":"plugins"} [plugins] loading firecrawl from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/firecrawl/index.js
2026-05-15T20:32:48.402Z debug plugins {"subsystem":"plugins"} [plugins] loading google from /home/hakalya/.npm-global/lib/node_modules/openclaw/dist/extensions/google/index.js
2026-05-15T20:32:48.428Z debug {"message":"web_search: no provider configured, auto-detected \"gemini\" from available API keys"} verbose
2026-05-15T20:32:53.664Z debug {"message":"web_search: no provider configured, auto-detected \"gemini\" from available API keys"} verbose

Das war die antwort vom agenten:

Getestet: Suche funktioniert, aber nicht über native Codex/OpenAI Web Search. Der Tool-Call kam als provider: gemini, model: gemini-2.5-flash zurück.

Query war: „Kitzingen heute 15. Mai 2026 Veranstaltungen was war los“

Gefundene Sachen laut Ergebnis:

• Stadtradeln 2026 in Kitzingen
• StadtSchoppen am Stadtbalkon, 17-22 Uhr
• Gebetstreffen Friedenskirche Kitzingen-Siedlung, 12 Uhr
• Darstädter Gitarrenkonzerte / Simon Eingang-Trio, 20 Uhr in der Musik Butik
• im Umland u.a. Ausstellungen in Dettelbach/Iphofen und Frühlingsfest im 99er Kulinarium

Citations kamen u.a. von stadt-kitzingen.de, kitzinger-land.de, meinestadt.de, allevents.in.

Nebenfund: Parameter wie country, language, freshness sind bei unserem aktuellen Provider-Fallback nicht sauber verfügbar: erst gemini, dann kimi, beide haben bestimmte Filter abgelehnt. Für den Upgrade-Plan ist das wichtig: wir müssen explizit prüfen/erzwingen, dass server-side web search wirklich über den OpenAI/Codex-Pfad läuft und nicht still über Gemini/Kimi fallbackt.

[vestal kayak]

Yep, this confirms it:

web_search: no provider configured, auto-detected "gemini" from available API keys

So in that run, OpenClaw did managed web_search via Gemini, not Codex-native web search. The agent model was still openai/gpt-5.5 on the Codex harness, but the search tool itself resolved to Gemini.

That means OpenClaw found a Gemini/Google web-search credential somewhere the gateway can see. It does not have to be a visible GEMINI_API_KEY in the config you’re looking at. Check these places on the gateway host, but don’t paste secret values:

openclaw config get tools.web.search.provider
openclaw config get plugins.entries.google.config.webSearch
openclaw config get models.providers.google
openclaw config get auth.profiles
openclaw models status --probe

[vestal kayak]

Also check gateway env / dotenv sources for at least presence:

env | rg '^(GEMINI_API_KEY|GOOGLE_API_KEY|GOOGLE_GENERATIVE_AI_API_KEY)='
[ -f ~/.openclaw/.env ] && rg 'GEMINI_API_KEY|GOOGLE_API_KEY|GOOGLE_GENERATIVE_AI_API_KEY' ~/.openclaw/.env

If the gateway runs as a service, remember its env can differ from your shell. openclaw status --all is useful because it redacts secrets and often shows where auth is coming from.

If you want to stop managed search from auto-picking Gemini, pin a provider explicitly or disable/remove that credential. For example, key-free DuckDuckGo:

openclaw config set tools.web.search.provider duckduckgo
openclaw gateway restart

If your goal is specifically “only Codex/native search, no managed Gemini search”, then the current trace shows you’re not there yet. The absence of these lines is the clue:

[vestal kayak]

activating Codex native web search ...
Injected Codex native web search tool into provider payload

Given your log says provider openai + runtime codex, I’m a bit suspicious the current native-search activation check may not treat that harness path as eligible in the same way as the legacy openai-codex / openai-codex-responses path. If pinning tools.web.search.openaiCodex.enabled=true still falls back to managed Gemini, that’s worth filing as a GitHub issue with these exact log lines: https://github.com/openclaw/openclaw/issues

[vestal kayak]

Ja, das bestätigt die Diagnose sauber.

In diesem Test waren zwei Dinge gleichzeitig wahr:

• Der Agent selbst lief über openai/gpt-5.5 mit runtime:"codex".
• Der Web-Lookup lief trotzdem über den managed web_search Provider gemini / gemini-2.5-flash.

Das ist also nicht “Codex subscription web search”. Es ist: Codex-Agent + OpenClaw-managed web_search + Gemini fallback.

Der Satz vom Agenten ist genau der richtige Befund:

wir müssen explizit prüfen/erzwingen, dass server-side web search wirklich über den OpenAI/Codex-Pfad läuft und nicht still über Gemini/Kimi fallbackt.

Pragmatische nächste Schritte:

1. Pinne managed search weg von Gemini, wenn du Gemini nicht willst:

[vestal kayak]

openclaw config set tools.web.search.provider duckduckgo
openclaw gateway restart

2. Oder teste “native Codex only” möglichst isoliert:

openclaw config set tools.web.search.openaiCodex.enabled true
openclaw config set tools.web.search.openaiCodex.mode cached
openclaw config unset tools.web.search.provider
openclaw gateway restart

3. Dann erneut Logs prüfen. Wenn weiterhin web_search: ... auto-detected "gemini" kommt und nicht:

activating Codex native web search ...

[vestal kayak]

Injected Codex native web search tool into provider payload

dann ist das sehr wahrscheinlich ein bug/edge case in der Aktivierung: provider:"openai" + runtime:"codex" wird offenbar nicht als native Codex-search-eligible behandelt, obwohl es vom Produktgefühl her so wirken sollte.

Das wäre dann ein gutes GitHub-Issue mit genau diesen drei Belegen:
• harness log: provider:"openai", modelId:"gpt-5.5", runtime:"codex"
• search log: auto-detected "gemini"
• agent result: provider: gemini, model: gemini-2.5-flash

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

[sinful mesa]

openclaw config get tools.web.search.provider
Config path not found: tools.web.search.provider. Run openclaw config validate to inspect config shape.

openclaw config get plugins.entries.google.config.webSearch
Config path not found: plugins.entries.google.config.webSearch. Run openclaw config validate to inspect config shape.

openclaw config get models.providers.google
{
"baseUrl": "https://generativelanguage.googleapis.com/v1beta",
"apiKey": "OPENCLAW_REDACTED",
"models": []
}

openclaw config get auth.profiles
{
"openai-codex:[e-mail]": {
"provider": "openai-codex",
"mode": "oauth"
},
"anthropic:claude-cli": {
"provider": "claude-cli",
"mode": "oauth"
},
"openai-codex:[e-mail]": {
"provider": "openai-codex",
"mode": "oauth"
}
}

(I actually tried to remove acc2 but somehow it seems to have come back here.. maybe I should remove all codex accs and readd / auth the one I want?)

openclaw models status --probe

env | rg '^(GEMINI_API_KEY|GOOGLE_API_KEY|GOOGLE_GENERATIVE_AI_API_KEY)='
[ -f ~/.openclaw/.env ] && rg 'GEMINI_API_KEY|GOOGLE_API_KEY|GOOGLE_GENERATIVE_AI_API_KEY' ~/.openclaw/.env
MGOOGLE_API_KEY=REDACTED

Test gemacht.

Befund:

• openclaw infer web providers zeigt aktuell nur gemini als Web-Search-Provider. Kein OpenAI/Codex server-side Search Provider in der Capability-Liste.
• Managed Websearch funktioniert: openclaw_web_search/infer web search läuft über Gemini und liefert Treffer.
• Agent-Turn mit openai/gpt-5.5 läuft über authMode: auth-profile, also Subscription/OAuth-Pfad klappt für Chat.
• Wenn ich den Agenten explizit „Websuche nutzen“ lasse, benutzt er OpenClaw web_search + web_fetch Tools, nicht OpenAI provider-native/server-side Websearch.

Kurz: Chat über Codex Subscription funktioniert. Websuche funktioniert auch, aber derzeit als OpenClaw-managed Tool über Gemini, nicht als OpenAI/Codex server-side Search. Das ist genau die Trennlinie, die wir gesucht haben.

[vestal kayak]

Ja, dein Befund passt zu dem, was die aktuellen Docs/Source sagen.

Wichtige Ergänzung: Es gibt inzwischen Codex-native Web Search, aber die ist opt-in unter tools.web.search.openaiCodex. Wenn die nicht aktiv ist, sieht dein Ergebnis genau so aus: Codex/OAuth für Chat, aber web_search läuft als OpenClaw-managed Tool über den erkannten Provider, bei dir Gemini.

Zum Gegencheck:

openclaw config get tools.web.search.openaiCodex
openclaw config get tools.web.search.enabled
openclaw infer web providers

Wenn du native Codex-Suche testen willst:

openclaw configure --section web

und dort „native Codex web search“ aktivieren, empfohlen erst mal cached. Manuell wäre die Form ungefähr:

[vestal kayak]

{
  tools: {
    web: {
      search: {
        enabled: true,
        openaiCodex: {
          enabled: true,
          mode: "cached"
        }
      }
    }
  }
}

Dann sollte bei openai-codex/* bzw. Codex-Responses-Modellen das managed web_search Tool unterdrückt werden und stattdessen das native web_search in den Codex Responses Payload injiziert werden. Für Nicht-Codex-Modelle bleibt managed Search.

[vestal kayak]

Zu acc2: Ich würde nicht als erstes alles löschen. Besser erst pinnen:

openclaw models auth order get --provider openai-codex
openclaw models auth order set --provider openai-codex 'openai-codex:[e-mail]'
openclaw models status --probe

Wenn acc2 nach Entfernen wieder auftaucht, kommt es vermutlich aus der per-Agent Auth-Profile-Store/Migration, nicht aus dem gerade editierten Config-Snippet allein. Relevant laut Docs: <agentDir>/auth-profiles.json, auth-state.json order overrides, und legacy OAuth imports aus ~/.openclaw/credentials/oauth.json.

Noch ein kleiner Fund: Falls MGOOGLE_API_KEY=... wirklich exakt so in deiner .env steht, ist das für Gemini Search kein gültiger Name. Erwartet wird GEMINI_API_KEY oder plugins.entries.google.config.webSearch.apiKey; GOOGLE_API_KEY ist zusätzlich bei Google model auth relevant. Docs: https://docs.openclaw.ai/tools/web und https://docs.openclaw.ai/tools/gemini-search 🦞

[sinful mesa]

openclaw config get tools.web.search.openaiCodex
{
"enabled": true,
"mode": "cached"
}

openclaw config get tools.web.search.enabled
true

openclaw infer web providers
{
"search": [
{
"available": true,
"configured": true,
"selected": false,
"id": "gemini",
"envVars": [
"GEMINI_API_KEY"
]
}
],
"fetch": []
}

[vestal kayak]

That confirms the split pretty cleanly:

• tools.web.search.openaiCodex.enabled: true + mode: cached means Codex-native search is enabled for Codex-capable model turns.
• infer web providers showing Gemini as available/configured but selected: false is not necessarily bad here. That list is about managed OpenClaw web-search providers. With native Codex search active, Codex turns can skip the managed web_search tool entirely.
• Gemini is still configured and available as the managed fallback for non-Codex models, or for cases where native Codex search is not eligible.

So the updated boundary is:

Codex subscription/OAuth:

• Chat/model turns for openai-codex/*
• Native Codex web search when tools.web.search.openaiCodex.enabled=true

Paygo/API-key side:

• Managed Gemini web search, because that uses GEMINI_API_KEY
• Other managed web-search providers, depending on provider/key
• Non-Codex OpenAI API routes if you use native OpenAI rather than Codex OAuth

[vestal kayak]

The remaining thing I’d check is whether the actual Codex turn log/attribution shows native search being injected instead of a tool call named web_search. If the transcript still shows the assistant calling OpenClaw web_search, then either the model/provider for that turn wasn’t actually Codex-eligible, or it used a runtime path that didn’t activate the Codex-native suppression.

[sinful mesa]

08:15:12+00:00 debug {"message":"web_search: no provider configured, auto-detected "gemini" from available API keys"} verbose
08:15:15+00:00 debug {"message":"web_search: no provider configured, auto-detected "gemini" from available API keys"} verbose
like that? ...

[vestal kayak]

Yes, that log is specifically the managed OpenClaw web_search tool path auto-detecting Gemini.

So if that log came from the same agent turn where you expected Codex-native search, native Codex search did not take over for that turn. The usual reasons would be:

• the actual model/provider for the turn was not openai-codex/* or not using api: "openai-codex-responses"
• the turn used a runtime path that still exposed managed web_search
• the config was changed but the gateway/agent process had not reloaded it yet
• the log line came from a non-Codex turn/tool test, not the Codex turn itself

Quick checks:

openclaw --version
openclaw models status --probe
openclaw config get agents.defaults.model
openclaw config get tools.web.search.openaiCodex
openclaw logs --follow

[vestal kayak]

Then run one fresh Codex turn after a gateway restart/reload. If native Codex search is active, I would not expect the web_search: ... auto-detected "gemini" line for that Codex turn, because the managed tool should be suppressed and the native web_search should be injected into the Codex Responses payload instead.

[sinful mesa]

openclaw --version
OpenClaw 2026.5.12 (f066dd2)

openclaw models status --probe
10:22:01 [plugins] memory-lancedb: injecting 3 memories into context
◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai/gpt-5.5
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (3) : or-minimax -> openrouter/minimax/minimax-m2.7, or-gemini31pro -> openrouter/google/gemini-3.1-pro-preview, gpt-mini -> openai/gpt-5.4-mini
Configured models (4): openrouter/minimax/minimax-m2.7, openrouter/google/gemini-3.1-pro-preview, openai/gpt-5.4-mini, openai/gpt-5.5

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

• elevenlabs effective=env:sk_3e62d...aaa36fcc | env=sk_3e62d...aaa36fcc | source=env: ELEVENLABS_API_KEY
• google effective=models.json:AIzaSyAq...mRLnJ-iI | models.json=AIzaSyAq...mRLnJ-iI | source=models.json: ~/.openclaw/agents/main/agent/models.json
• openai effective=env:sk-proj-...uLxfIqkA | env=sk-proj-...uLxfIqkA | source=env: OPENAI_API_KEY | models.json=sk-proj-...uLxfIqkA | source=models.json: ~/.openclaw/agents/main/agent/models.json
• openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:[e-mail]=OAuth ([e-mail])
• openrouter effective=env:sk-or-v1...31f9ecd0 | env=sk-or-v1...31f9ecd0 | source=env: OPENROUTER_API_KEY | models.json=sk-or-v1...31f9ecd0 | source=models.json: ~/.openclaw/agents/main/agent/models.json
• perplexity effective=env:sk-or-v1...31f9ecd0 | env=sk-or-v1...31f9ecd0 | source=env: OPENROUTER_API_KEY

OAuth/token status

• openai-codex usage: 5h 90% left ⏱2h 38m · Week 65% left ⏱2d 16h
  • openai-codex:[e-mail] ([e-mail]) ok expires in 10d

Auth probes

continue 1 / 2 ...

[vestal kayak]

Aha, this explains it.

Your default is:

Default: openai/gpt-5.5

That is the OpenAI API provider path, not the OpenAI Codex OAuth provider path. So for that turn, Codex-native web search is not eligible, and OpenClaw falls back to managed web_search -> Gemini. It also means the chat turn is likely using your OPENAI_API_KEY / paygo path, not the Codex subscription OAuth path.

For Codex subscription/OAuth you want the provider to be openai-codex, e.g. conceptually:

openai-codex/gpt-5.5

Check what model IDs are available in your picker/status, then switch the session/default to the Codex provider variant. If you use a chat command, it should be the Codex provider/profile, not plain openai/gpt-5.5.

[vestal kayak]

So current diagnosis:

• openai/gpt-5.5 = OpenAI API key/paygo
• openai-codex/... = Codex OAuth/subscription
• Gemini web_search log is expected while you’re on openai/gpt-5.5

Send the rest of the probe output too, but this line is already the smoking claw. 🦞

[sinful mesa]

running OpenClaw 2026.5.12 with openai/gpt-5.5 via Codex (ChatGPT) sub.

Goal: use Codex-native / OpenAI web search, not OpenClaw web_search routed through gemini/...

What works:

• Agent runs through Codex harness:
• agentHarnessId: "codex"
• model: openai/gpt-5.5
• auth: openai-codex
• OpenClaw dynamic web_search works, but only through configured OpenClaw search providers such as gemini.

Minimal test:

OPENCLAW_STATE_DIR=/tmp/openclaw-codex-only
openclaw agent --local --agent main
--session-id codex-native-search-only-test
--thinking medium
--message 'There is no OpenClaw web_search/web_fetch tool available. Use Codex/OpenAI native web search if available to find one current official OpenAI Codex documentation URL. Reply with NATIVE_SEARCH_USED=yes/no and the URL. If no native search, say NATIVE_SEARCH_USED=no.'
--json

Test setup:

• plugins.allow = ["openai", "codex"]
• openclaw infer web providers --json returns {"search":[],"fetch":[]}
• auth uses local ~/.codex:
  • auth.order.openai = ["openai-codex:default"]
• OpenClaw web tools blocked:
  • tools.deny = ["web_search", "web_fetch"]
  • plugins.entries.codex.config.codexDynamicToolsExclude = ["web_search", "web_fetch"]

Result:

{
"finalAssistantVisibleText": "NATIVE_SEARCH_USED=no",
"agentMeta": {
"provider": "openai",
"model": "gpt-5.5",
"agentHarnessId": "codex"
}
}

Docs that confused me:

• Codex harness docs mention OpenClaw dynamic web_search:
  /home/hakalya/.npm-global/lib/node_modules/openclaw/docs/plugins/codex-harness.md:449-469
• OpenAI provider docs mention server-side web search as “Native OpenAI Responses tool”:
  /home/hakalya/.npm-global/lib/node_modules/openclaw/docs/providers/openai.md:84-90

Q:
Is Codex-native server-side web search expected to work in OpenClaw Codex harness for openai/gpt-5.5 with ChatGPT/Codex OAuth?
If yes, what config enables it? If no, should the docs clarify that only OpenClaw dynamic web_search is available here?

[vestal kayak]

I checked current docs/source. Short answer: for OpenClaw 2026.5.12 + Codex app-server harness, I do not see a config path that enables Codex/OpenAI server-side web search from OpenClaw.

What I see in source:

• Codex harness thread/start gets: model, modelProvider, cwd, approval/sandbox/serviceTier, developer instructions, and OpenClaw dynamicTools.
• It does not pass an app-server web_search / tools.web_search config in the thread/start, thread/resume, or turn/start payload.
• The Codex app-server protocol has web-search-ish types/events, but OpenClaw’s bridge in 2026.5.12 does not appear to wire OpenClaw config into those.
• The tools.web.search.openaiCodex logic I found is for the PI/OpenClaw Responses path: eligible when provider is openai-codex or model API is openai-codex-responses. Your harness run reports agentHarnessId: "codex", provider: "openai", so that path is not the one being used.

So for your exact setup:

openai/gpt-5.5 + embeddedHarness.runtime: "codex"

Expected today: Codex harness can use OpenClaw dynamic web_search, which then routes through OpenClaw providers like Gemini/Brave/etc. If you remove/deny those tools and no app-server native search config is sent, NATIVE_SEARCH_USED=no is the expected result.

[vestal kayak]

If you want to test OpenClaw’s Codex-native Responses search path, I’d test the PI route instead:

{
  agents: {
    defaults: {
      model: { primary: "openai-codex/gpt-5.5" }
    }
  },
  tools: {
    web: {
      search: {
        enabled: true,
        openaiCodex: { enabled: true, mode: "cached" }
      }
    }

[vestal kayak]

  }
}

That is separate from the Codex app-server harness.

I agree the docs should clarify this. The OpenAI provider page’s “Server-side web search: Native OpenAI Responses tool” reads too broad next to the Codex harness docs. It should probably say something like: native OpenAI/Codex Responses web search applies to the OpenClaw/PI Responses provider paths, while the Codex app-server harness currently exposes web search via OpenClaw dynamic tools unless/until the harness bridge wires app-server native web_search config.

Good GitHub issue material: https://github.com/openclaw/openclaw/issues

[sinful mesa]

Thanks, I tested both variants in an isolated state dir w/o running doctor.

Test state: /tmp/openclaw-codex-pi-test

1. openai-codex/gpt-5.5
   Config was valid, and:

OPENCLAW_STATE_DIR=/tmp/openclaw-codex-pi-test
openclaw models list --provider openai-codex --json

does list openai-codex/gpt-5.5.

Agent run succeeded, but it still reported:

{
"provider": "openai-codex",
"model": "gpt-5.5",
"agentHarnessId": "codex",
"toolSummary": {
"tools": ["web_search"]
},
"finalAssistantVisibleText": "SEARCH_USED=no"
}

So this did not seem to use a separate PI / Responses-native search path. It still looked like the Codex harness / OpenClaw dynamic tool path.

2. openai/gpt-5.5 with explicit PI runtime
   I then tested:

{
agents: {
defaults: {
model: { primary: "openai/gpt-5.5" },
models: {
"openai/gpt-5.5": {
agentRuntime: { id: "pi" }
}
}
}
},
tools: {
web: {
search: {
enabled: true,
openaiCodex: { enabled: true, mode: "cached" }
}
}
}
}

With Codex OAuth / ChatGPT subscription auth only, and no OPENAI_API_KEY, the run failed with:

No API key found for provider "openai".
You are authenticated with OpenAI Codex OAuth; OpenAI agent model runs use openai/gpt-* through the Codex runtime.
Set OPENAI_API_KEY only for direct OpenAI API-key surfaces.

I did not test with OPENAI_API_KEY, because that would be direct paygo API usage, not ChatGPT/Codex subscription usage.

Currently I can't find a working native server-side web search path with Codex OAuth / subscription auth:

• openai-codex/gpt-5.5 runs, but still reports agentHarnessId: "codex" and uses the OpenClaw dynamic tool path.
• openai/gpt-5.5 + agentRuntime.id: "pi" seems to require direct OpenAI API key auth.
• The Codex app-server harness works, but only OpenClaw dynamic web_search appears usable there.

Is there a config needed to force the PI/OpenAI-Codex-Responses path while still using Codex OAuth / ChatGPT subscription auth?

[vestal kayak]

I think the missing piece is harness selection, not web-search config.

If openai-codex/gpt-5.5 reports:

"agentHarnessId": "codex"

then you are not on the PI/OpenAI-Codex-Responses path for that run. You are still in the Codex app-server harness, so only OpenClaw dynamic web_search is available. In source, the bundled Codex harness normally supports provider codex; it only runs for other refs if it is forced/pinned by harness policy/session state.

Things to check:

env | rg '^OPENCLAW_AGENT_RUNTIME|^OPENCLAW_AGENT_HARNESS'
openclaw config get agents.defaults.embeddedHarness
openclaw config get agents.main.embeddedHarness

[vestal kayak]

For the PI subscription path, use openai-codex, not openai, and force the embedded harness to PI with a fresh session:

{
  agents: {
    defaults: {
      model: { primary: "openai-codex/gpt-5.5" },
      embeddedHarness: {
        runtime: "pi",
        fallback: "pi"
      }
    }
  },
  tools: {
    web: {
      search: {

[vestal kayak]

        enabled: true,
        openaiCodex: { enabled: true, mode: "cached" }
      }
    }
  }
}

Then run with a brand-new --session-id, because OpenClaw pins the selected harness into session state after the first turn. If a session already recorded agentHarnessId: "codex", later config changes will not move that same session to PI.

Also: using ~/.codex auth is the Codex app-server harness auth path. For PI + openai-codex/*, make sure the isolated state dir actually has an OpenClaw openai-codex auth profile:

OPENCLAW_STATE_DIR=/tmp/openclaw-codex-pi-test \
openclaw models auth login --provider openai-codex --device-code

[vestal kayak]

Your second test is expected: openai/gpt-5.5 + pi means direct OpenAI provider under PI, so without OPENAI_API_KEY it fails. That is not the subscription path.

So the config to try is: openai-codex/gpt-5.5 + OpenClaw openai-codex auth profile + embeddedHarness.runtime: "pi" + fresh session. If that still reports agentHarnessId: "codex", then something is forcing/pinning the harness and the debug log for agents/harness should show exactly why.

[sinful mesa]

I checked this against 2026.5.12 schema/docs and tested it.

embeddedHarness exists in the schema, but it is marked legacy. The schema says runtime selection ignores it and provider/model runtime policy should be used instead. Current docs also say whole-session and whole-agent runtime pins are
ignored, including stale session agentHarnessId state.

Checks:

• No OPENCLAW_AGENT_RUNTIME / OPENCLAW_AGENT_HARNESS env vars are set.
• agents.defaults.embeddedHarness and agents.main.embeddedHarness are not configured.
• The schema marks agents.defaults.embeddedHarness.runtime as “Legacy whole-agent embedded harness runtime. Runtime selection ignores it.”
• I tested the supported model-scoped path with fresh sessions.

Results:

• openai-codex/gpt-5.5 still selected agentHarnessId: "codex".
• openai/gpt-5.5 + model agentRuntime.id: "pi" did try PI, but failed without OPENAI_API_KEY, even with auth.order.openai explicitly set to the named openai-codex:[e-mail] OAuth profile.
• Error: “No API key found for provider openai. You are authenticated with OpenAI Codex OAuth; OpenAI agent model runs use openai/gpt-* through the Codex runtime.”

So I don’t think this is session pinning or missing embeddedHarness. In 2026.5.12, embeddedHarness appears stale/legacy. The current doc says the right control is provider/model agentRuntime.id.

The remaining issue looks like either:

1. docs mismatch: openai/gpt-5.5 + agentRuntime.id: "pi" does not actually accept selected openai-codex OAuth profiles, despite docs saying it should; or
2. a bug in the OpenAI provider/auth routing for PI + Codex OAuth.

Useful sources:

• docs/concepts/agent-runtimes.md:151-155
• docs/plugins/sdk-agent-harness.md:119-124
• docs/providers/openai.md:156-160
• config schema: embeddedHarness legacy/runtime ignored, provider/model agentRuntime preferred

[vestal kayak]

You’re right. My last answer was leaning on the older embeddedHarness path; your 2026.5.12 test evidence is stronger, and the current model-scoped agentRuntime.id behavior is the relevant one.

Given your results, I’d summarize the current state as:

• openai-codex/gpt-5.5 + subscription auth is being routed to agentHarnessId: "codex", so it uses Codex app-server harness behavior.
• Codex app-server harness currently exposes OpenClaw dynamic tools; it does not appear to expose a separate OpenAI/Codex server-side web-search path through OpenClaw config.
• openai/gpt-5.5 + agentRuntime.id: "pi" forces PI, but PI treats provider openai as direct OpenAI API-key auth. Selecting/ordering an openai-codex:* OAuth profile under auth.order.openai does not make that route use Codex OAuth.
• So I do not see a working config in 2026.5.12 that gives: PI runtime + openai/gpt-5.5 + ChatGPT/Codex OAuth + OpenAI/Codex native server-side web search.

That points to a docs/behavior mismatch at minimum. The clean issue would be:

Codex OAuth + native server-side web search routing unclear/unavailable in 2026.5.12

Expected:
A documented way to use ChatGPT/Codex OAuth with native OpenAI/Codex server-side web search, or docs saying this is not currently supported.