OpenCode Go rejects Codex tool schemas with a root-level oneOf

[CissiBot]

Description

When OpenCode Go is configured as an OpenAI-compatible custom provider in Codex (ChatGPT Desktop), requests that include the built-in automation_update function fail during tool-schema validation, before model inference starts.

The emitted function.parameters is a JSON Schema with a root-level $defs and oneOf. Every branch is an object schema, but the parameters schema itself has no top-level type. OpenCode Go / Console Go rejects this shape and requires tools[].function.parameters.type to be "object".

Steps to Reproduce

1. Configure https://opencode.ai/zen/go/v1 as an OpenAI-compatible custom provider in Codex / ChatGPT Desktop.
2. Send a non-streaming chat completion request to /v1/chat/completions using deepseek-v4-flash and the following tool schema.
3. Use an OpenCode Go API key in the Authorization header.

export OPENCODE_GO_API_KEY='REDACTED'
curl -sS https://opencode.ai/zen/go/v1/chat/completions \
  -H "Authorization: Bearer ${OPENCODE_GO_API_KEY}" \
  -H 'Content-Type: application/json' \
  --data-binary @request.json

request.json:

{
  "model": "deepseek-v4-flash",
  "messages": [
    {"role": "user", "content": "schema compatibility probe"}
  ],
  "stream": false,
  "tool_choice": "auto",
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "automation_update",
        "description": "Create, update, view, or delete recurring automations.",
        "parameters": {
          "$defs": {
            "stringValue": {"type": "string"}
          },
          "oneOf": [
            {
              "type": "object",
              "additionalProperties": false,
              "properties": {
                "mode": {"type": "string", "enum": ["view"]},
                "id": {"$ref": "#/$defs/stringValue"}
              },
              "required": ["mode", "id"]
            },
            {
              "type": "object",
              "additionalProperties": false,
              "properties": {
                "mode": {"type": "string", "enum": ["delete"]},
                "id": {"$ref": "#/$defs/stringValue"}
              },
              "required": ["mode", "id"]
            }
          ]
        }
      }
    }
  ]
}

Expected Behavior

The provider should accept a root-level oneOf when its branches are object schemas, or document the supported subset and provide a compatible normalization path.

Actual Behavior

The request is rejected with HTTP 400 before inference:

Error from provider (Console Go): Upstream request failed:
[invalid_request_error] Invalid schema for function 'automation_update':
schema must be a JSON Schema of 'type: "object"', got 'type: null'.

Adding only this property to function.parameters:

"type": "object"

made the same minimal request return HTTP 200 for both deepseek-v4-flash and kimi-k3.

Environment

• Client: Codex / ChatGPT Desktop
• Provider: OpenCode Go
• Endpoint: https://opencode.ai/zen/go/v1/chat/completions
• Models tested: deepseek-v4-flash, kimi-k3
• Protocol: OpenAI-compatible Chat Completions

Additional Context

The full automation_update schema emitted by Codex has the same root shape ($defs plus oneOf) as the reduced reproduction above. The failure is independent of thinking/reasoning settings and occurs during tool-schema validation, before model inference.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Bug: Anthropic models error Input_schema does not support oneOf, allOf, or anyOf at the top level #37916: Same class of problem — root-level oneOf/allOf/anyOf in tool schemas being rejected; that issue tracks the Anthropic adapter path, while this one targets the OpenCode Go (Console Go) endpoint directly.
• [Bug] OpenCode Go: Kimi K2.6 rejects tool schemas with if/then/else conditionals #31580: OpenCode Go rejecting non-standard JSON Schema constructs (if/then/else) for Kimi models — same provider, same pattern of strict schema validation before inference.

If your issue is distinct (e.g. it specifically affects the OpenCode Go proxy when external clients submit oneOf-without-type schemas, rather than schemas generated by OpenCode itself), please clarify that so maintainers can triage accordingly.