Field: custom tools to function

What it does

Codex 0.15x ships apply_patch only as a Responses custom/freeform tool (type: custom plus a Lark grammar). Grok and CPA-style adapters drop or ignore custom tools, so the model only sees JSON function tools such as exec_command.

This transform rewrites matching custom tool descriptors to JSON functions on the request, including history ToolCall nodes and tool_choice, then restores tool_type = custom on the response so Codex still receives custom_tool_call.

The function schema uses a single required string field input holding the full *** Begin Patch document. Lark grammar enforcement is not preserved.

Grok often emits *** Begin Patch *** / *** End Patch ***. Codex requires the first line to be exactly *** Begin Patch. The response phase rewrites those headers (and strips *** End of File *** / <invoke> wrappers) before Codex parses the patch.

Grok also emits Add File bodies as raw file lines. Codex requires each Add File content line to start with +. The response phase prefixes + on those raw lines. It does not prefix lines that already start with +, -, or \, and it stops prefixing at @@ hunk headers. Update File hunks keep - deletions.

The request schema tells the model to insert with a leading-space context line plus + new lines. Do not clone an unchanged line as both - and +. The response phase drops those identical -/+ hunks so Codex does not accept an empty edit.

Reference

When to use

• Codex talks to Grok through CPA or another adapter that strips type: custom.
• Add two rules with the same config: one request rule and one response rule.
• Place the request rule before the upstream encode. Place the response rule so it runs on the decoded Grok stream.

Configuration

Example rule

{
  "transform": "field_custom_tools_to_function",
  "enabled": true,
  "phase": "request",
  "models": ["grok-*"],
  "config": {}
}

Use the same config with "phase": "response".