[Bug] Declared tools intermittently rejected with "unsupported call: <tool>" in Codex Desktop (web search + connector tools) with a custom model catalog

What version of the Codex App are you using (From "About Codex" dialog)?

Codex Desktop on Windows, MSIX package OpenAI.Codex_26.924.2738.0_x64 (bundled codex-cli 0.156.1).

What subscription do you have?

Not verified from inside the session. The session runs the built-in openai model provider with a custom model slug supplied through model_catalog_json.

What platform is your computer?

Windows 11 x64, PowerShell 7.

What issue are you seeing?

Tool calls to declared, schema-visible tools are intermittently rejected by the Codex tool dispatcher with the literal error:

unsupported call: <tool_name>

Affected tools observed in a single session include both connector/MCP-backed tools and the built-in web search tool:

• web.run (built-in web search)
• mcp__codex_apps__github___search_issues, mcp__codex_apps__github___get_profile (GitHub connector)
• mcp__codex_app__check_app_update, mcp__codex_app__list_projects
• mcp__ghidra__list_instances

The tool schemas are present in the session's model-visible tool list, so this is not a "tool never exposed" case. The model emits a call for a tool the session advertised, and the dispatcher rejects it. Local functions.* tools (exec_command, apply_patch) keep working in the same session at the same time.

What steps can reproduce the bug?

1. Configure a custom model through model_catalog_json and start a Codex Desktop session on it.
2. Call any connector-backed tool, for example a GitHub connector search, or the built-in web search tool.
3. Observe unsupported call: <tool_name>. Retrying the identical call sometimes succeeds and sometimes fails.

Observed intermittency (single session, in order)

1. One batch of three GitHub connector calls (get_repo, search_issues x2) succeeded normally.
2. Immediately afterwards, every connector call in the same session was rejected: search_issues (x4), get_profile (x2), check_app_update, list_projects, list_instances.
3. Earlier, web.run succeeded on its first attempt; a few minutes later the identical call failed twice and then succeeded; in the following turn it failed on 8 consecutive attempts.
4. The web.run failures are independent of arguments: a single query, a four-query batch, response_length set to short/medium/long/omitted, and even an empty query {"q": ""} all returned the identical unsupported call: run.

Environment (sanitized)

# %USERPROFILE%\.codex\config.toml (relevant lines only)
model = "commandcode-goat/deepseek-v4.1-flash"
model_provider = "openai"
model_catalog_json = "%USERPROFILE%\\.codex\\token-model-catalog.json"
standalone_web_search = true

The custom catalog entry for this model sets "supports_search_tool": false and "shell_type": "shell_command", and has no tool_mode field.

What is the expected behavior?

A tool call whose name matches a declared session tool should either dispatch normally or fail with a precise capability or authorization error. The dispatcher should not intermittently answer unsupported call for tools that the session advertised to the model.

Additional information

• This looks adjacent to, but distinct from, the existing custom-provider MCP reports (#22970, #31354, #26977, #44984, #36382, #47839). Those describe tools that are never exposed, or a provider-specific namespace/deferred-loading problem. Here the schemas are visible, plain local tools keep working, and the same connector call alternates between success and unsupported call within one running session.
• An exhaustive duplicate search was not completed because the GitHub connector itself is affected by this bug; its search calls are rejected intermittently.