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

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.