[Provider]: xAI Responses opt-in (grok-4.x) 400s on codex_app automation_update — openai-responses path skips root-schema flattening #2753

Client or integration

Codex App (Codex Desktop 0.150.0-alpha.8, which injects the built-in codex_app automation MCP toolset into every routed request)

Provider or upstream service

xai (api.x.ai, OAuth)

OpenCodex version

2.33.0 (@bitkyc08/opencodex)

Endpoint or capability

/v1/responses — the xAI native Responses opt-in (xaiResponsesOptIn), which flips providers.xai.modelAdapters for grok-4.6/grok-4.5 from openai-chat to openai-responses; affects client tool declarations / tool calls.

Current behaviour

An existing Codex Desktop thread runs normally while grok-4.6 routes through the provider-level openai-chat adapter: consecutive requests return 200 with the full tool list, including the built-in mcp__codex_app__* automation tools.

After the xAI Responses opt-in is enabled and routing switches to openai-responses, the very next sampling attempt of the same thread fails upstream with HTTP 400 in ~2.5 s. Every further turn fails identically because the same client tool list is redeclared on every request — the thread becomes unusable until the adapter is reverted.

Upstream rejects the Codex App automation_update tool, whose parameter schema root is an anyOf union containing a nested union (i.e. a non-object branch); minimized shape, same family as #122:

{
  "anyOf": [
    { "type": "object", "properties": { "...": { } } },
    { "oneOf": [ { "type": "object" }, { "type": "object" } ] }
  ]
}

Per xAI's function-calling docs, a root oneOf/anyOf is only accepted when every branch is directly an object schema; nested unions count as non-object branches.

Timeline from usage.jsonl (single proxy instance, same conversation ID, same tool catalog throughout — the only delta is the selected adapter):

10:30:21 UTC   adapter=openai-chat        -> 200
10:31:20 UTC   adapter=openai-chat        -> 200
               < xaiResponsesOptIn enabled; modelAdapters rewritten >
10:52:04 UTC   adapter=openai-responses   -> 400 invalid_request_error (first attempt, ~2.5 s)

Expected behaviour

Routing grok-4.6/grok-4.5 through the native Responses path should apply the same xAI-specific tool-schema sanitization the openai-chat adapter already performs (normalizeXaiToolParameters, introduced by #124 for #122): flatten the union root when the merge is lossless, and otherwise omit just the incompatible tool rather than forwarding a declaration xAI is guaranteed to reject. Today a single built-in Codex App tool poisons the entire request.

Minimal redacted request or reproduction

1. Log in to xAI OAuth, pick xai/grok-4.6 in Codex Desktop under default openai-chat routing, confirm turns succeed.
2. Enable the native Responses opt-in (dashboard toggle or management API):

curl -X PUT http://127.0.0.1:<port>/api/providers/<provider-config-route> \
  -H 'Authorization: Bearer <admin-token>' \
  -H 'Content-Type: application/json' \
  -d '{"xaiResponsesOptIn": true}'

3. Continue the same Codex App thread (its requests carry the built-in codex_app automation tools).
4. Continuation returns 400 invalid_client_tool_schema naming mcp__codex_app__automation_update, and every subsequent turn repeats it.

Adapter-dependence check: earlier in the very same thread, the identical tool list produced 200s while routed through openai-chat; switching routing to openai-responses reproduces the 400 deterministically.

Actual response or error

HTTP 400
{"code":"invalid-argument","error":"Failed to start sampling: [invalid_client_tool_schema] mcp__codex_app__automation_update: tool parameter root must be an object type (root schema is an anyOf/oneOf union with a non-object branch)"}

Proxy-side record: status 400, errorCode: invalid_request_error, adapter openai-responses, first attempt.

Upstream documentation

https://docs.x.ai/developers/tools/function-calling#parameter-schema — parameter schemas for function calling; root oneOf/anyOf accepted only when all branches are direct object schemas (the same requirement quoted in #122).

Suggested mapping or implementation notes

• normalizeFunctionToolSchema on the responses path (src/adapters/openai-responses.ts, around line 505) only stamps "type": "object" next to existing keywords when the root is not an object. A root holding anyOf/oneOf still ships as a union, and when a branch is itself a union xAI rejects the whole request — the sibling type keyword does not neutralize the union for their validator.
• For isXaiSchemaTarget providers, reuse/export the lossless root-flattening from normalizeXaiToolParameters (src/adapters/openai-chat.ts) in the responses translation step. Where flattening is not lossless, dropping just the offending tool (the chat adapter's behavior) keeps the thread alive — the other codex_app tools carry plain object roots.
• Ideally make the opt-in/discovery layer aware of this so enabling xaiResponsesOptIn cannot silently regress previously-working threads.

Additional context and attachments

• Same tool + provider pair as [Bug]: xAI/Grok 400 after tool_search loads automation_update's nested oneOf schema #122 (closed via PR fix(xai): normalize nested tool schemas #124), which fixed exactly this automation_update schema on the openai-chat path; the newer native-Responses opt-in opens a second entry point that bypasses that normalization.
• Related precedent of adapter-scoped schema-normalization gaps: [Bug]: Kimi returns 400 when a Codex tool schema has no root object type #228 (Kimi 400 when a Codex tool schema has no root object type), [Provider]: Kimi/Moonshot 400 — $ref with sibling keywords in tool schema $defs is not normalized (openai-chat adapter) #2673 ($ref with sibling keywords not normalized on the chat adapter).

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• The expected behaviour is based on an upstream specification or a concrete client requirement.