Anthropic 400: messages.0.content.N.text.text Field required (message content serialization)

[BuomEm]

Client or integration

Codex App

Area

Provider adapter

Summary

Anthropic 400: messages.0.content.N.text.text Field required — malformed content block in messagesToAnthropicFormat

When using an Anthropic (Claude) backend, the proxy returns 400 with messages.0.content.11.text.text: Field required. The content block at that index has a text field that is an object instead of a string, or is missing the text field entirely. This is in message content serialization (messagesToAnthropicFormat), not tool schema normalization (#75 / #76).

Reproduction

1. ocx start
2. Configure provider as Anthropic Claude (claude-opus-4-6-thinking or claude-sonnet-4-20250514) via any upstream (e.g. google-antigravity)
3. Use Codex for a session with multiple tool calls (shell_command, apply_patch, etc.) until conversation history is large
4. On the next request, observe 400 error:
   Provider error 400: {"type":"error","error":{"type":"invalid_request_error","message":"messages.0.content.11.text.text: Field required"}}

Version

2.7.39

Operating system

Windows 11 24H2

Provider and model

google-antigravity / claude-opus-4-6-thinking

Logs or error output

Provider error 400: Antigravity invalid request: {"type":"error","error":{"type":"invalid_request_error","message":"messages.0.content.11.text.text: Field required"},"request_id":"req_vrtx_011CdMAczCSM59wSQkjpFyBQ"}

{
  "requestId": "ocx-mrz4rxnw-3h",
  "timestamp": 1784909071148,
  "model": "claude-opus-4-6-thinking",
  "provider": "google-antigravity",
  "requestedModel": "google-antigravity/claude-opus-4-6-thinking",
  "status": 400,
  "durationMs": 1645,
  "errorCode": "invalid_request_error",
  "closeReason": "non_stream",
  "upstreamError": "Provider error 400: Antigravity invalid request: {\"type\":\"error\",\"error\":{\"type\":\"invalid_request_error\",\"message\":\"messages.0.content.11.text.text: Field required\"},\"request_id\":\"req_vrtx_011CdMAczCSM59wSQkjpFyBQ\"}",
  "usageStatus": "unreported",
  "displayMetrics": {
    "tokPerSecond": {
      "kind": "unavailable",
      "reason": "usage_missing"
    },
    "cost": {
      "kind": "unavailable",
      "reason": "usage_missing"
    }
  }
}

Screenshots and supporting files

No response

Redacted configuration

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[HaydernCenterpoint]

@BuomEm Hmm, this bug is fixed already and i can use model from Antigravity really smooth. You should reinstall or show me how you connect to Codex/Claude/Github Copilot App and i will support you how to fix it.

[BuomEm]

Thanks for the response. I tried doing a clean reinstall, but the issue still persists.

First, I removed OpenCodex using both:

ocx uninstall
npm uninstall -g @bitkyc08/opencodex

Then I reinstalled it with:

npm install -g @bitkyc08/opencodex

After reinstalling, I started seeing this warning:

[opencodex] Provider model discovery for "google-antigravity" failed with HTTP 404 [urlClass=provider-models, fallback=configured].

More importantly, the original Antigravity error still occurs:

Provider error 400: Antigravity invalid request: {"type":"error","error":{"type":"invalid_request_error","message":"messages.0.content.11.text.text: Field required"},"request_id":"req_vrtx_011CdNE8u16BYp1bU6awZaPV"}

So a complete uninstall and reinstall did not resolve the messages.0.content.N.text.text: Field required issue.

I’m still able to reproduce the same Antigravity 400 error after a clean reinstall.

[lidge-jun]

🔒 Fix in progress — assigned to the maintainer integration pass

@lidge-jun (maintainer) is actively working this issue. Please do not open a competing PR
for it until this marker is removed; duplicate work would have to be discarded.

The fix is being integrated on the maintainer branch codex/260725-pr-rework (based on
dev) together with regression coverage that pins the reported failure mode. Verification
before merge: bun run typecheck, the full bun run test suite, bun run privacy:scan,
bun run lint:gui, then exact-SHA hosted Cross-platform CI and Service lifecycle.

This issue will be closed with an evidence comment naming the integration commit SHA, the
code that closes each reported path, and the verification output. If you have additional
reproduction detail, it is still very welcome here.

_{Integration tracker: devlog/_plan/260725_pr_issue_rework · marker posted by the maintainer integration pass}

[lidge-jun]

Fixed in dev

Commit: 74795ad6 (PR #430 by @snowyukitty) · merged into dev at ebc62d1f

Every serialization branch that could emit an empty or malformed content part is now closed in src/adapters/google.ts:

• a user/developer message with empty string content emits a non-empty placeholder instead of {"text":""}
• empty or malformed text parts are dropped; if that leaves nothing, the placeholder is used
• an assistant turn with no emittable parts is skipped entirely rather than sent as parts: []
• an empty tool result gets its own placeholder instead of a phantom [image] marker

Antigravity translates these Gemini contents into Anthropic messages, and a proto3 empty string is omitted from the translated JSON — which is why this surfaced as messages.N.content.M.text.text: Field required only on Claude-through-Antigravity.

Verification

• bun test tests/google-empty-content.test.ts: 14 pass / 0 fail
• Reverting the guard fails 12 of those 14, so the fix is demonstrably what closes the path
• Full suite at merge: 4222 pass / 0 fail (327 files); typecheck, privacy scan, GUI lint all clean
• Cross-platform CI on ebc62d1f: success on ubuntu, macOS, and Windows (6/6 jobs)

Thanks for the report — the empty-parts assistant turn was the harder half to spot.