Codex review: needs real behavior proof before merge. Reviewed June 24, 2026, 8:02 AM ET / 12:02 UTC.

Summary
The branch changes the agent web tool runtime context helper and tests so agent web_search always keeps runtime provider discovery enabled while web_fetch retains bundled-owner manifest gating.

PR surface: Source -4, Tests -22. Total -26 across 3 files.

Reproducibility: yes. at source level: current main can set preferRuntimeProviders false for a manifest-owned configured search provider, and createWebSearchTool forwards that into runWebSearch. I did not live-reproduce the multi-hour gateway uptime failure.

Review metrics: 1 noteworthy metric.

• Provider precedence split: 1 changed, 1 preserved. The diff changes agent web_search discovery precedence while preserving web_fetch bundled-owner handling, which is the compatibility choice maintainers need to review.

Stored data model
Persistent data-model change detected: vector/embedding metadata: src/agents/tools/web-tool-runtime-context.test.ts. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #87347
Summary: This PR is the direct open fix candidate for the canonical agent-side web_search runtime-provider divergence; the broader explicit-provider routing PR overlaps but is not the clean canonical landing path right now.

Members:

• canonical: [Bug]: Agent-side web_search resolves to "no provider available" while CLI infer web search and plugins inspect confirm Brave is loaded #87347 - The issue is the open user report for agent-side web_search diverging from loaded Brave provider state and is referenced by this PR with closing syntax.
• partial_overlap: [codex] Fix explicit custom web_search provider routing #77736 - The PR changes explicit web_search provider routing in the same files, but it is broader, currently conflicting, and reviewed as needing reconciliation with this runtime-first direction.
• adjacent_distinct: feat(web-search): add explicit provider fallback support #63571 - The PR adds explicit provider fallback behavior for web_search, which is adjacent provider-routing work but not the same no-provider runtime registry regression.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🐚 platinum hermit
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P1] Add redacted live Brave-backed agent or gateway web_search terminal output, logs, or a recording from this head; redact API keys, IP addresses, phone numbers, non-public endpoints, and other private details.
• Have provider/runtime ownership confirm the intended split: web_search runtime-first at the agent boundary, web_fetch still bundled-owner gated.
• Coordinate landing order with [codex] Fix explicit custom web_search provider routing #77736 so explicit web_search routing semantics do not diverge.

Proof guidance:

• [P1] Needs stronger real behavior proof before merge: The PR body provides tests and a summarized resolver smoke, but no inspectable redacted agent/gateway web_search output for the changed provider path. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

• [P1] The PR intentionally changes agent web_search provider-resolution precedence, so maintainers should confirm no supported configured search setup depends on the old manifest-owner gate before runtime registry lookup.
• [P1] The public proof is still not inspectable real behavior proof for the changed path; tests and a summarized resolver smoke do not show redacted Brave-backed agent or gateway web_search output from this head.
• [P2] [codex] Fix explicit custom web_search provider routing #77736 overlaps explicit web_search routing semantics, so landing order should avoid contradictory provider-precedence or fallback behavior.

Maintainer options:

1. Require provider-path proof (recommended)
   Ask for redacted live Brave-backed agent or gateway web_search terminal output, logs, or a recording from this exact head showing the configured provider resolves through the runtime registry while web_fetch remains bundled-owner gated.
2. Accept maintainer-owned validation
   Maintainers can intentionally land with the public proof gap only if they have separately validated the provider path and own that evidence outside the PR.
3. Coordinate with broader routing work
   Pause this PR or land it first only if the broader explicit-provider routing PR rebases around the runtime-first search contract.

Next step before merge

• [P1] Manual review remains because the blocker is real behavior proof plus provider/runtime owner confirmation, not a narrow code repair an automated worker can safely apply.

Security
Cleared: The diff changes provider-resolution control flow and tests only; it adds no dependency, workflow, lockfile, package, secret-handling, or supply-chain surface.

This direction makes sense to me. Search is much more sensitive to the live runtime registry than fetch, so keeping web_search runtime-first while leaving the bundled-owner fetch gate alone looks like the right split.

The main thing I’d want maintainers to sanity-check is whether there are any scenarios where a configured search provider is intentionally not supposed to use an already-loaded runtime instance. If the answer is “no,” then dropping the early manifest-owner lookup here seems like the cleanest way to bring agent web_search back in line with infer web / runtime inspection behavior.

Fixes #87347

What Problem This Solves

Fixes an issue where agent-side web_search could report that no provider was
available even when the configured provider was loaded in the live runtime.

Why This Change Was Made

The agent tool was making a manifest-owner decision before runWebSearch could
use the active runtime provider registry. Search now stays runtime-first at the
agent boundary; runWebSearch remains responsible for downstream provider
scoping. web_fetch keeps its existing bundled-owner behavior.

User Impact

Configured manifest-owned search providers remain available to agent-side
web_search when their plugin is loaded in the current runtime.

Evidence

• Current main: 4d034639adfdcfd58ac8d793fdea625c88897428
• Focused Vitest: 4 files, 48 tests passed
• Changed-file oxlint: passed
• git diff --check: passed
• Production resolver smoke: search preferRuntimeProviders=true; bundled fetch false
• Autoreview: 0 findings
• No live Brave request was run; credentials were not available

rebased again because main advanced during merge preparation.

• new base: 63874fa0d1194675fa6a96a7178ea187d971afa6
• new head: 20ea0781092db9bc3291b672c8f49c6d363ddfc0
• focused rerun: 4 files, 48 tests passed

The diff remains the same three-file owner-boundary fix.

Maintainer update: the merge guard caught relevant mainline drift. I rebased the maintainer-editable branch onto the exact current main and force-updated it with a lease.

The PR remains the same three-file web-search owner-boundary fix. Fresh exact-head hosted checks are running before the guarded merge retry.

Maintainer update: main advanced to 2a484a3ff10 during the previous hosted run. The PR branch is now rebased onto that exact head and force-updated with a lease; the three-file diff is unchanged. Fresh checks are starting for this exact head.

Merged via squash.

• Prepared head SHA: bf13efd818344ba647bc28fa296db00b901517d7
• Merge commit: af2b0a6118bc72d9d9d8eba1d62a18ce33b08abf

Thanks @alexzhu0!