[Provider compatibility] Codex App plugins unavailable for routed models when catalog forces supports_search_tool=true

[Eleven-is-cool]

Client or integration

Codex App

Provider or upstream service

OpenAI-compatible third-party provider

OpenCodex version

2.11.1

Endpoint or capability

/v1/responses; Codex App plugin/MCP tool discovery

Current behaviour

OpenCodex generates Codex model-catalog rows for non-Cursor routed models with:

{
  "supports_search_tool": true,
  "web_search_tool_type": "text_and_image"
}

With this generated catalog entry, Codex App does not expose the Browser plugin's deferred MCP tools to the routed model. In a fresh task, the model cannot see or call tools such as mcp__node_repl__js, and reports that the browser runtime cannot be initialized.

A controlled A/B test changes only supports_search_tool:

• true (OpenCodex-generated default): Browser plugin tools are absent from the model-visible tool surface.
• false: a new Codex App task exposes the direct MCP tools, including mcp__node_repl__js, and the routed model can call them.

No provider, model, plugin, Codex App, or OpenCodex version changed between the two runs.

Expected behaviour

OpenCodex should generate a catalog capability profile that makes Codex App plugins usable for routed third-party models.

If the tool_search compatibility path is supported for a provider/model, deferred plugin discovery should complete and load the requested tools. If that path is not verified for the routed model, OpenCodex should advertise supports_search_tool: false so Codex exposes compatible direct MCP tools instead.

A generated capability flag should not make the Browser plugin silently unavailable.

Minimal redacted request or reproduction

Environment:
- macOS
- Codex App 26.803.61601
- bundled Codex CLI 0.147.0-alpha.6.5
- OpenCodex 2.11.1
- OpenAI-compatible third-party provider
- DeepSeek-compatible routed model
- Browser plugin enabled

1. Let OpenCodex generate/sync its Codex model catalog.
2. Confirm the routed model entry contains:
   "supports_search_tool": true
3. Start a fresh Codex App task with the routed model.
4. Ask it to use the Browser plugin.
5. Observe that deferred Browser MCP tools such as mcp__node_repl__js are not present in the model-visible tool surface.
6. Change only the routed entry to:
   "supports_search_tool": false
7. Apply the same value to the active Codex model cache, then start another fresh task.
8. Ask it to use the Browser plugin again.
9. Observe that direct MCP tools, including mcp__node_repl__js, are now present and callable.

Actual response or error

No HTTP error is returned.

Failing/default case:
- supports_search_tool: true
- Browser deferred MCP tools absent
- routed model concludes that the required browser runtime tool is unavailable

Working A/B case:
- supports_search_tool: false
- mcp__node_repl__js appears in the tool surface
- the routed model successfully issues direct MCP calls

This is a tool-discovery/capability-advertisement failure rather than an upstream model HTTP failure.

Upstream documentation

Concrete client requirement: Codex App's enabled Browser plugin must remain discoverable and callable when using an OpenCodex-routed model.

Relevant OpenCodex implementation:
https://github.com/lidge-jun/opencodex/blob/main/src/codex/catalog/parsing.ts

Related but different prior issue demonstrating the intended routed-model tool_search compatibility path:
#122

Suggested mapping or implementation notes

In normalizeRoutedCatalogEntry, non-Cursor routed rows currently receive supports_search_tool = true unconditionally.

Suggested options:

1. Make search-tool support a provider/model capability instead of a blanket routed-model default.
2. Verify the generated tool_search path end-to-end with Codex App plugins before advertising it.
3. Default unverified routed models to supports_search_tool: false, preserving direct MCP exposure.
4. Add a regression test covering Browser plugin discovery for both catalog values.

Additional context and attachments

I searched existing provider and compatibility issues. No matching report was found.

Issue #122 is related only as evidence that OpenCodex intentionally translates Codex tool_search for routed models. It covers an incompatible loaded schema after discovery, whereas this report covers plugin tools not becoming available at all.

All provider names, model routing identifiers, local paths, task IDs, account details, and internal service information were removed. This issue intentionally excludes a separate MCP result-formatting observation so the reproduction stays focused on discovery.

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• The expected behaviour is based on an upstream specification or a concrete client requirement.

[Ingwannu]

I can reproduce the catalog-side part of this report on current dev: normalizeRoutedCatalogEntry advertises supports_search_tool=true for every non-Cursor routed row, without any provider/model capability check. Your controlled A/B result is therefore consistent with a real compatibility defect in the generated catalog.\n\nI am going to fix this conservatively: keep the existing sidecar-backed web_search_tool_type for non-Cursor routes, but stop advertising deferred search-tool support by default for routed models. That preserves hosted web-search routing while letting Codex expose direct MCP/plugin tools instead of selecting an unverified deferred-discovery surface. I will add focused catalog regressions for both ordinary routed rows and Cursor, run the catalog suite and typecheck, then open a dev-targeted draft PR and report the exact head here. The runtime tool_search parser/bridge will remain intact for clients that explicitly send that wire shape.

[Ingwannu]

The conservative fix is now available in draft PR #1529, targeting dev at exact head 29fd4f024d5cf82d3db3909026c8dcf4b114af73.

What changed:

• routed rows now default supports_search_tool to false, keeping Codex App's compatible direct MCP/plugin tools visible;
• non-Cursor rows still advertise web_search_tool_type: "text_and_image", so the existing hosted web-search sidecar is not removed;
• Cursor remains without hosted-search metadata because its transport bypasses that sidecar;
• the runtime tool_search parser/bridge remains intact for explicit client wire requests.

Verification on the exact head:

• focused catalog/parity suite: 176 passed, 0 failed;
• typecheck passed;
• privacy scan passed;
• diff check passed.

The full local suite was externally terminated with SIGTERM/143 late in the run rather than failing an affected assertion. One unrelated shim test was also shown to depend on the host's pre-existing API-token environment and passes 67/67 when isolated. I am leaving the PR in draft pending exact-head repository CI and independent maintainer review; I will not self-approve or self-merge it.

[Wibias]

Fixed by #1515