Support function-backed Code Mode exec for providers without custom/freeform tool support

Summary

Code Mode currently assumes that the public exec tool can be represented using the provider's custom/freeform tool capability. This creates a compatibility gap for Responses API providers that support function calling but do not support custom tools.

I suggest adding a compatibility path where Code Mode exec can be exposed as a normal function tool when custom/freeform tools are unavailable.

Motivation

Some third-party Responses-compatible providers (for example DeepSeek) can support:

• Responses API transport
• function tools
• tool calls
• structured JSON arguments

but do not support OpenAI-specific custom/freeform tool types.

In this case Codex enables Code Mode based on model metadata, but the session cannot expose the core exec capability because the tool representation is incompatible.

The current situation creates an unnecessary coupling:

Code Mode availability
        |
        v
custom/freeform tool support

However, the execution model itself does not fundamentally require custom tools. A function-backed exec interface can carry the same information:

{
  "name": "exec",
  "arguments": {
    "code": "..."
  }
}

Proposed design

Add a fallback conversion:

ToolSpec::Freeform(exec)
        |
        | provider does not support custom tools
        v
ToolSpec::Function(exec)
        |
        v
ToolPayload::Function
        |
        v
existing Code Mode execution runtime

The runtime implementation could remain unchanged if the execution handler accepts both representations.

Why this fits existing architecture

Related issues already show similar compatibility conversions:

• deferred tools being converted into Code Mode function definitions
• provider capability mismatches caused by assuming OpenAI-hosted capabilities
• custom model providers requiring capability-aware tool selection

The general principle would be:

Tool representation should be selected from provider capabilities, not only model metadata.

Reproduction

Environment:

• Codex CLI with Code Mode enabled
• custom Responses API provider
• provider supports function tools but not custom/freeform tools

Observed behavior:

Code Mode is enabled, but the model does not support the custom/freeform tool required by exec.

Expected behavior:

Codex exposes exec as a function tool and continues using Code Mode.

Benefits

• Better compatibility with DeepSeek and other Responses-compatible providers
• Keeps Code Mode architecture available outside OpenAI-hosted models
• Avoids requiring every provider to implement OpenAI-specific custom tool formats
• Provides a cleaner capability-driven abstraction for future providers

This is not intended as provider-specific support, but as a general tool capability fallback.