Feature request: expose a provider-compatible native edit tool for third-party models

Summary

Codex advertises support for third-party/custom model providers, but third-party models currently do not receive the same native file-editing capabilities as OpenAI models. In particular, apply_patch is often absent from the tool list or cannot be used because the provider only accepts a different tool schema.

This makes third-party model support feel incomplete: the model can connect, call shell_command, and even find the injected apply_patch executable in the session environment, but it cannot call apply_patch as a first-class Codex tool.

Reproduction

1. Configure a custom provider such as MiniMax, Azure, Ollama, or LM Studio.
2. Use a custom model catalog entry.
3. Try to enable apply_patch with:

"apply_patch_tool_type": "freeform"

1. Ask the model to edit a file.

Depending on the provider and Codex version, one of the following happens:

• apply_patch is not present in the model's tool list.
• The model prints a patch as plain text instead of invoking a tool.
• The provider rejects the generated custom/freeform tool schema.
• The model can only invoke apply_patch indirectly through exec_command.

The current workaround is to run the session-injected apply_patch command through Shell, but that is not equivalent to exposing the native tool. The executable path is also session-local and unstable, for example:

~/.codex/tmp/arg0/<random-session>/apply_patch

Why this matters

Third-party model support should ideally mean feature parity for the Codex runtime, not only endpoint connectivity. File editing is a core coding-agent capability. Without a native edit tool, custom providers are forced to rely on fragile prompt behavior or Shell workarounds.

The current setup also makes debugging unnecessarily difficult because the relevant behavior depends on internal model metadata such as:

• apply_patch_tool_type
• base_instructions
• provider-specific tool schema compatibility

Suggested improvements

1. Make native edit-tool support explicitly configurable

Allow users to declare tool compatibility per provider/model, for example:

[model_providers.minimax]
...
apply_patch_tool_type = "function"

or in the model catalog:

{
  "tools": {
    "shell": "shell_command",
    "file_edit": "function"
  }
}

The configuration should support at least:

• standard function tools
• freeform/custom tools
• disabled tools

2. Provide a compatibility fallback

If a provider cannot accept the native freeform tool, Codex should be able to expose a standard JSON function wrapper that accepts a patch string, then execute the same safe patch engine locally.

This would allow providers that support ordinary function calling to use file editing without requiring the provider to understand OpenAI-specific freeform tool types.

3. Improve model-catalog diagnostics

When a model has no apply_patch capability, Codex should report why:

• tool disabled by catalog
• provider schema incompatible
• unsupported tool type
• missing model metadata

A startup diagnostic such as the following would be very helpful:

Model MiniMax-M3: apply_patch disabled
Reason: provider only supports standard function tools; catalog requests freeform
Suggested configuration: apply_patch_tool_type = "function"

4. Rename or alias the tool to something more understandable

apply_patch is an implementation-oriented name. It is familiar to Unix developers, but it is not immediately clear to users or many models that it edits files.

Please consider exposing a user/model-facing alias such as:

• edit_file
• apply_file_changes
• modify_file

while keeping apply_patch as an internal compatibility alias.

A tool description such as this would also help:

edit_file:
Apply a structured, context-checked change to one or more files in the workspace.

The implementation can remain patch-based while the public tool name becomes self-explanatory.

Expected behavior

When a custom provider supports standard function calling, Codex should be able to expose a first-class file-editing tool with a provider-compatible schema:

edit_file({
  "patch": "..."
})

The Codex host should execute the patch locally, apply the same workspace and permission checks used by the native tool, and return a structured result to the model.

This would preserve the safety and atomicity of patch-based editing while making third-party provider support reliable and understandable.