OpenClaw Turns Codex Hosted Search Into a Bounded Tool Provider Instead of a Whole-Agent Commitment

The useful version of multi-agent architecture is not “let everything call everything.” That is just distributed confusion with better branding. The useful version is narrower: give one runtime a specific capability from another runtime, strip away everything it does not need, and make the result observable enough that operators can tell what happened. OpenClaw PR #93446 is interesting because it treats Codex hosted web search exactly that way.

The PR adds a Codex app-server web-search planner that prefers Codex hosted web_search when supported while preserving OpenClaw’s managed web_search fallback. More importantly, it lets an operator set tools.web.search.provider: "codex" even when the parent model is not Codex. That means a Claude-backed, OpenAI-backed, local-model-backed, or otherwise non-Codex OpenClaw run can delegate search to Codex as a bounded provider rather than moving the whole agent loop into Codex.

That distinction is the story. “Codex has web search” is a feature note. “OpenClaw can use Codex search as a scoped capability lane without giving Codex the whole workspace” is an architecture note.

The boundary is the feature

The PR is large — 3,353 additions, 461 deletions, 48 changed files, and two commits — because the hard part is not calling search. The hard part is preventing search delegation from becoming accidental runtime delegation. The explicit-provider path runs inside an ephemeral, isolated Codex thread. That worker disables shell environments, dynamic tools, apps, plugins, image generation, multi-agent mode, and code mode. The path fails closed unless Codex emits a native hosted-search item. Native hosted search and managed search stay mutually exclusive. Domain, context, and location restrictions are projected into the Codex thread config.

That is the right paranoia. A web search provider should not inherit a shell just because the underlying product can run one. It should not get plugins because the parent runtime has plugins. It should not become a second agent with broad authority simply because hosted search is convenient. If a platform says “use Codex for search,” the operator should be able to read that literally: search, not search-plus-tools-plus-workspace-plus-shell.

This is where a lot of agent integrations go wrong. Developers wire one impressive capability into another runtime and accidentally import the whole security model behind it. The demo works, the boundary blurs, and six weeks later nobody can explain why a search task had access to a private filesystem path. PR #93446 is careful in the way production agent systems need to be careful: minimal authority, explicit provider selection, constrained inputs, observable output, and failure when the expected native action is absent.

The verification details are unusually useful. The PR reports 388 tests across three Vitest shards, another 31 tests across Codex web/media/provider files, 26 plugin contract tests, pnpm tsgo:core, pnpm tsgo:extensions, pnpm tsgo:test:src, and pnpm build. It also includes a live proof with a non-Codex parent model using tools.web.search.provider: "codex", returning provider: "codex", model: "gpt-5.5", one hosted search action, and isError: false. The marker ROSITA_CODEX_PROVIDER_CROSS_MODEL_OK is a nice little breadcrumb: this was not just type-level aspiration.

Portability is becoming composition, not migration

The timing fits the larger Codex, Claude Code, OpenCode, and Gemini CLI comparison cycle. Developers keep asking which agent they should move to. That is a reasonable question, but it is becoming less complete every month. The better question is which runtime should own orchestration, which model should own reasoning for a given task, and which provider-native tools should be exposed as scoped services.

Codex hosted search may be valuable even for teams that do not want Codex as their main coding agent. Claude may remain the preferred planning and code-review lane. A local Qwen or DeepSeek model might handle cheap summarization. OpenClaw may own channel routing, cron, memory, approvals, and cross-tool policy. In that architecture, migration is not the only path. Composition is.

Composition is only sane if every capability has a crisp boundary. Search should return search results. A summarizer should not mutate files. A background worker should not inherit Slack posting rights unless that is the job. A provider-native tool should not silently downgrade to a broader managed tool with different policy semantics unless the operator asked for that fallback. PR #93446’s mutually exclusive native-vs-managed search handling is important for exactly this reason: ambiguity is where auditability goes to die.

Practitioners should read this as a checklist for their own agent stacks. If you delegate across runtimes, write down what authority crosses the boundary. Is the delegated worker ephemeral? Does it inherit the parent transcript, or a minimized projection? Does it receive tool policy, network restrictions, location/domain constraints, and side-question context? Does it fail closed when the requested provider cannot produce the expected native action? Can logs prove which provider actually handled the operation?

Those questions matter more than the marketing label on the agent. A “best AI coding agent 2026” comparison that does not evaluate delegation boundaries is reviewing a car by looking only at horsepower. Power is useful. Brakes are also part of the product.

The risk to watch is configuration drift. Cross-runtime capability routing creates more places for policy to diverge: Codex app-server behavior, OpenClaw managed search behavior, domain filters, transcript projection, side forks, provider availability, and fallback decisions. The PR’s test volume should not be dismissed as ceremony. For this kind of feature, the boundary tests are the feature.

OpenClaw’s move here is pragmatic. It does not insist that Codex become the whole agent. It does not pretend OpenClaw’s own search provider is always enough. It says: use the better capability when available, but keep it fenced. That is the pattern serious agent platforms will need if the category keeps fragmenting into specialized runtimes with specialized model-native tools.

The editorial take: Codex search as a bounded OpenClaw provider is more important than Codex search as a checkbox. The future is not one agent to rule them all. It is capability routing with least privilege, or it is a security incident waiting for a changelog.

Sources: OpenClaw PR #93446, OpenAI Codex changelog, OpenAI Codex CLI features