Codex provider fails on nullable anyOf output schemas

[grantjayy]

Summary

clawpatch ci --provider codex fails against Codex CLI / OpenAI-compatible Responses strict structured output when the provider schema contains nullable fields emitted as anyOf.

The failure occurs before model reasoning. Codex CLI rejects the generated schema:

invalid_json_schema
strict json_schema type must be a string or a non-empty array of strings
param: text.format.schema.properties.findings.items.properties.evidence.items.properties.endLine.type

Environment

• clawpatch: 0.7.0 (latest npm at time of report)
• Codex CLI: 0.142.3
• provider: codex
• model: gpt-5.5
• route: OpenAI-compatible Responses API via codex-pooler
• OS observed: macOS

Minimal reproduction

rm -rf /tmp/clawpatch-pooler-smoke
mkdir -p /tmp/clawpatch-pooler-smoke
cd /tmp/clawpatch-pooler-smoke

git init -q
git config user.email smoke@example.com
git config user.name 'Smoke Test'

cat > sample.py <<'PY'
def add(a, b):
    return a + b
PY

git add sample.py
git commit -q -m init

cat > sample.py <<'PY'
def add(a, b):
    return a + b

def subtract(a, b):
    return a - b
PY

clawpatch ci \
  --since HEAD \
  --include-dirty \
  --provider codex \
  --model gpt-5.5 \
  --reasoning-effort xhigh \
  --jobs 1 \
  --output clawpatch-codex.md

Observed result:

clawpatch review feature-error ... error=codex provider failed: OpenAI Codex v0.142.3
...
ERROR: {"error":{"code":"invalid_json_schema","message":"strict json_schema type must be a string or a non-empty array of strings","param":"text.format.schema.properties.findings.items.properties.evidence.items.properties.endLine.type","type":"invalid_request_error"},"status":400,"type":"error"}

Root cause

dist/provider-schema.js currently generates provider schemas via:

z.toJSONSchema(schema, { io: "input", unrepresentable: "any" })

For nullable fields like evidenceLineSchema:

const evidenceLineSchema = z.number().int().min(0).nullable();

Clawpatch emits JSON Schema like:

{
  "anyOf": [
    { "type": "integer" },
    { "type": "null" }
  ]
}

That is valid generic JSON Schema, but Codex CLI's --output-schema / Responses strict schema path does not accept it. I isolated the compatibility issue with direct Codex CLI probes:

• schema using anyOf: [{"type":"integer"},{"type":"null"}] fails with the same ...endLine.type error.
• equivalent schema using "type": ["integer", "null"] succeeds.

Locally validated fix

I patched the installed package locally to normalize the exact nullable anyOf pattern into a strict-compatible type array before handing the schema to Codex.

Conceptual patch:

function normalizeNullableAnyOf(schema) {
  const anyOf = schema["anyOf"];
  if (!Array.isArray(anyOf) || anyOf.length !== 2) return;

  const nullIndex = anyOf.findIndex(
    (item) => isRecord(item) && item["type"] === "null" && Object.keys(item).length === 1,
  );
  if (nullIndex === -1) return;

  const other = anyOf[nullIndex === 0 ? 1 : 0];
  if (!isRecord(other) || typeof other["type"] !== "string") return;

  delete schema["anyOf"];
  for (const [key, item] of Object.entries(other)) {
    schema[key] = item;
  }
  schema["type"] = [other["type"], "null"];
}

Called from stripProviderUnsupportedSchemaKeywords() after recursively stripping nested schema fields.

After applying that local normalization, the same real Codex-path smoke test passed:

clawpatch review feature-done ... findings=0
clawpatch review done ... reviewed=1 findings=0
EXIT_CODE=0

Expected behavior

clawpatch ci --provider codex should emit a Codex/Responses-compatible strict schema for nullable fields, or otherwise avoid using nullable anyOf in the Codex provider schema path.

Notes

This may also be valid to fix in Codex CLI by accepting/normalizing nullable anyOf, but Clawpatch can make its Codex provider path robust today by normalizing this common nullable shape itself.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 30, 2026, 5:21 PM ET / 21:21 UTC.

Summary
Keep open: current main still lacks nullable anyOf normalization in the provider schema path, and the linked open fix PR is a candidate implementation rather than a merged fix.

Reproducibility: yes. The current source still sends nullable evidence-line schema fields through the Codex --output-schema path without normalization, and the issue includes a command-level real Codex reproduction.

Root-cause cluster
Relationship: canonical
Canonical: #146
Summary: This issue is the canonical report, and the linked open PR is the candidate fix for the Codex nullable schema failure.

Members:

• fixed_by_candidate: fix(provider): normalize nullable schemas for Codex #147 - The PR body uses closing syntax for this issue and its diff directly targets nullable anyOf normalization in provider schema conversion.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Next step
No additional repair lane is needed while #147 is the open candidate fix for this issue.

Review details

Best possible solution:

Land #147 or an equivalent provider-schema normalization with regression coverage, then close this issue from the merged fix.

Do we have a high-confidence way to reproduce the issue?

Yes. The current source still sends nullable evidence-line schema fields through the Codex --output-schema path without normalization, and the issue includes a command-level real Codex reproduction.

Is this the best way to solve the issue?

Yes. The narrowest maintainable solution is to normalize the Zod-emitted nullable anyOf shape inside src/provider-schema.ts and cover it in src/provider.test.ts, which is exactly the linked fix direction.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The full external Codex CLI/codex-pooler smoke was not rerun during this read-only review, though the source path and reporter-provided real-path probe make the bug boundary high confidence.
• The linked fix PR is still open, so this issue should remain open until that PR merges or maintainers choose another implementation.

Codex review notes: model internal, reasoning high; reviewed against 24763d26cdff.

Label changes

Label changes:

• add clawsweeper:linked-pr-open: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• remove clawsweeper:queueable-fix: Current issue advisory state no longer selects this label.
• remove clawsweeper:fix-shape-clear: Current issue advisory state no longer selects this label.

Label justifications:

• P1: The report shows a current Codex provider workflow failing before review execution on the latest released path.
• impact:auth-provider: The affected behavior is the Codex provider adapter and selected provider/model route failing during strict schema handoff.

Evidence reviewed

What I checked:

• Current provider schema conversion: providerJsonSchema() on current main only calls Zod JSON Schema generation and strips unsupported keywords; it has no nullable anyOf to type: [T, "null"] normalization. (src/provider-schema.ts:23, 24763d26cdff)
• Nullable field source: evidenceLineSchema is still z.number().int().min(0).nullable() and feeds both startLine and endLine, matching the reported rejected schema path. (src/types.ts:229, 24763d26cdff)
• Codex strict schema handoff: runCodexJson() writes the generated schema and passes it to Codex with --output-schema, so this schema compatibility problem blocks the provider before reasoning. (src/providers/codex.ts:75, 24763d26cdff)
• Existing regression coverage gap: Current provider schema tests cover numeric keyword stripping, enum typing, and strict objects, but not nullable anyOf compatibility. (src/provider.test.ts:359, 24763d26cdff)
• Linked open fix PR: GitHub reports fix(provider): normalize nullable schemas for Codex #147 as open and mergeable, with closing syntax for this issue and a two-file fix in src/provider-schema.ts and src/provider.test.ts. (aafe2cbc8e0b)
• Candidate fix shape: The PR branch adds nullable anyOf recognition and a regression asserting evidence endLine has type: ["integer", "null"] and no anyOf. (src/provider-schema.ts:42, aafe2cbc8e0b)

Likely related people:

• steipete: Blame and commit API metadata tie the provider schema converter, nullable evidence schema, and recent Codex adapter path to this author. (role: introduced behavior and recent provider area contributor; confidence: high; commits: 0cd24d07a262, 0aff68a31070, d1928f471899; files: src/provider-schema.ts, src/types.ts, src/providers/codex.ts)
• coletebou: History shows prior merged work tolerating optional, null, and zero fields in review output schema tests and types, adjacent to this nullable schema compatibility area. (role: adjacent provider schema contributor; confidence: medium; commits: 7cad18b3433c; files: src/types.ts, src/provider.test.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[clawsweeper]

🦞✅
Implementation PR opened: #147
Status: The implementation PR passed the worker's edit, validation, review, publish, and post-flight gates.
Worker: https://github.com/openclaw/clawsweeper/actions/runs/28462997665