Codex Desktop custom provider app/dynamic tools end turns without function_call after automation_update-related prompts

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

Codex Desktop app: observed with Desktop-backed local sessions using codex-cli 0.142.0 in rollout metadata.

What subscription do you have?

Custom OpenAI-compatible provider / self-hosted proxy. The same user can create/delete automations from OpenAI official provider/model sessions, but custom provider sessions fail as described below.

What platform is your computer?

macOS / Darwin arm64.

What issue are you seeing?

In Codex Desktop sessions using a custom OpenAI-compatible Responses API provider, app/dynamic tool workflows can degrade into a state where the assistant emits a short planning/preamble message and the turn immediately completes with no function_call at all.

This is especially easy to trigger around Codex Desktop automations / codex_app.automation_update / app tools, but after the affected threads enter this state, the user observes that other tool-using requests also stop making progress. The user-visible symptom is: Codex says something like “I will check the available tools” or “I will use the automation tool”, then the turn ends. No tool call follows, and no useful answer is produced.

Two affected local session ids:

• 019f10fb-e0c9-7240-be03-84ad28d3ceb7, thread title: “检查 GitLab 证书更新”, provider: beaconfire_newapi, wire API: Responses, CLI/runtime metadata: 0.142.0
• 019f1156-9a02-7612-9b57-5503fd094ab4, thread title: “检查会话可见 automation_update”, provider: beaconfire_newapi, wire API: Responses, CLI/runtime metadata: 0.142.0

The same sessions were able to use ordinary tools earlier. For example, in the GitLab certificate thread, shell tool calls such as exec_command ran normally during the certificate diagnosis. The failure started around requests to create/check Codex Desktop automations or inspect automation tool availability.

Representative rollout evidence from the affected threads:

• User asked to create a Codex Desktop automation. Assistant replied: “I will use the Codex Desktop automation tool ... first check the available automation management tool schema.” The turn then completed. Recorded function calls: none.
• User asked whether the current session can see automation_update. Assistant replied: “I will check the current thread’s exposed dynamic tool list...” The turn then completed. Recorded function calls: none.
• User later asked to search whether this is a known Codex bug. Assistant emitted a preamble saying it would check memory/docs/online sources, made only limited local reads, then completed before doing the promised follow-up search.

This differs from an explicit tool runtime error: there is no visible unsupported call message and no Invalid schema for function automation_update error in the rollout. It looks like the model/client/provider path fails to produce or route a function_call for app/dynamic tools, then the turn is considered complete anyway.

What steps can reproduce the bug?

1. Configure Codex Desktop to use a custom OpenAI-compatible provider using the Responses wire API.

Example config shape:

model_provider = "beaconfire_newapi"
model = "gpt-5.5"

[model_providers.beaconfire_newapi]
name = "Beaconfire new-api"
base_url = "https://example-proxy.local/v1"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

1. In a Codex Desktop thread using that custom provider, ask for a Codex Desktop automation or ask whether automation_update / automation app tools are available.
2. Observe that the assistant may say it will inspect or use the automation/app tool, but no function_call is emitted and the turn completes.
3. Continue the same thread with another tool-using request. The thread may keep producing preambles without actually calling tools.

What is the expected behavior?

If the current custom provider/session supports app and dynamic tools:

• Codex should emit the intended function_call, such as tool discovery or the relevant app/dynamic tool call.
• If the provider cannot support that tool shape, Codex should surface a clear model-visible and user-visible error instead of ending the turn after a planning sentence.

If the provider/session does not support Codex app tools or deferred dynamic tools:

• Codex should not instruct the assistant that those tools are available.
• The UI/runtime should give a diagnostic explaining that app/dynamic tools are unavailable for the active provider or provider capability settings.

Related issues / PRs

This appears related to, but not identical with:

• #26977: MCP tools return “unsupported call” with custom Responses API provider.
• #26234: Flatten MCP namespace tools for non-OpenAI Responses API providers.
• #29602: Flatten namespace tools for providers without wrappers. This PR was still open/not merged when checked.
• #29128: Codex Desktop inconsistently exposes automation_update across local threads.
• #30132: automation_update schema / oneOf causing Azure endpoint schema error. This report is different: there is no visible schema rejection; the function_call is not emitted.

Additional information

Important diagnostic distinction: this does not look like the older Codex Desktop “unknown conversation” UI routing issue. The local rollout records show normal task completion events, but the suspicious turns complete with no function_call after the assistant emits a planning/preamble response.

Workaround currently used by the user:

• Avoid relying on Codex Desktop automations / automation_update from custom provider sessions.
• Create/delete automations only from OpenAI official provider/model sessions.
• Treat affected custom-provider threads as read-only history and continue work in a fresh healthy thread.