#Cloud Code Assist API error (400): Invalid JSON payload received

1 messages · Page 1 of 1 (latest)

ionic forum
#

Hi everyone, does anyone face some issue. I just change my gemini api key and oauth for antigravity. somehow after restart I got error from the openclaw.

Cloud Code Assist API error (400): Invalid JSON payload received. Unknown name "patternProperties" at 'request.tools[0].function_declarations[3].parameters.properties[2].value': Cannot find field.

Lemme know if anyone know how to fix it or might be a bug not sure. I have check this and already fixed at version 2026.2.17 but I face this issuw with version 2026.2.19-2

cloud tokenBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

somber shuttleBOT
#

That error is almost always Cloud Code Assist (the google-antigravity / “Antigravity OAuth” endpoint) rejecting OpenClaw’s tool JSON-schema.

Cloud Code Assist only accepts a strict subset of JSON Schema, and it will 400 on keywords like patternProperties (exactly what you’re seeing).

Quick workaround (get unstuck fast)

Restrict tools only for that provider so OpenClaw doesn’t send the “fancy” tool schemas to Cloud Code Assist:

{
tools: {
byProvider: {
"google-antigravity": { profile: "minimal" }
}
}
}
#

Then run:

openclaw doctor
openclaw gateway restart

Docs for this knob: https://docs.openclaw.ai/gateway/configuration-reference (see Tools → tools.byProvider)

If you still want tools

Two common options:

  1. Use the Gemini API-key provider (google) for tool-heavy agents, and keep Antigravity for simpler chat (Antigravity is the one that behaves like Cloud Code Assist and is pickier about schemas).
    Provider overview: https://docs.openclaw.ai/concepts/model-providers

  2. If you must stay on Antigravity: selectively deny the tool(s) that trigger complex schemas (often UI tools like browser/canvas), via tools.byProvider["google-antigravity"].deny.

#

To confirm + help triage the regression

Can you paste (they’re safe; tokens are redacted):

openclaw --version
openclaw models status
openclaw status --all

If 2026.2.17 worked and 2026.2.19-2 broke, that sounds like a regression worth a GitHub issue (include the outputs above + the exact provider/model it’s trying).

jolly yarrow
somber shuttleBOT
#

Yeah — a couple alternatives, depending on what you’re trying to achieve:

1) Hard-disable all tools just for google-antigravity (no schemas sent at all)

This is the most “nuke it from orbit” way to avoid Cloud Code Assist’s JSON-schema subset limitations:

{
  tools: {
    byProvider: {
      "google-antigravity": {
        deny: ["*"]
      }
    }
  }
}
#

That should prevent OpenClaw from sending any tool declarations to that endpoint (so no patternProperties to get rejected).

Docs: https://docs.openclaw.ai/gateway/configuration-reference (see tools.allow/deny + tools.byProvider)

2) Keep a tiny safe tool set instead of profile:"minimal"

If you still want some tools with Antigravity, start from minimal and add only the simple ones (usually group:web is safe):

{
  tools: {
    byProvider: {
      "google-antigravity": {
        profile: "minimal",
        allow: ["group:web"]
      }
    }
# 
  }
}

If it still 400s, remove group:web and add tools back one-by-one until you find the offender (it’s typically the more complex schemas like UI/browser-style tools).

3) Avoid the Antigravity bridge entirely (use Gemini API instead)

If you don’t need the Cloud Code Assist / Antigravity OAuth endpoint, switching your model/provider from google-antigravity/... → google/... (Gemini API key) sidesteps this whole “tool schema subset” issue.

(OpenClaw docs explicitly call out that google-antigravity/... is the Cloud Code Assist-style endpoint.)

4) Let it fail over automatically to a tool-friendly provider/model

If you want to keep Antigravity as “nice when it works” but not have it break runs, configure fallbacks so a 400 causes OpenClaw to move on.

Docs: https://docs.openclaw.ai/concepts/model-failover (agents.defaults.model.fallbacks)

#

If you paste your agents.defaults.model (just the provider prefixes are fine) + whether you need tools on Antigravity, I can suggest which of the above is the least painful setup.

jolly yarrow
jolly yarrow
#

When responding let me know how these 2 can we used within openclaw now that they cant access files and tools ("google-antigravity/claude-opus-4-6-thinking": {},, "google-antigravity/claude-opus-4-5-thinking": {},)

somber shuttleBOT
#

Those two models are still totally usable in OpenClaw — just not as “agentic/tooling” models right now.

Think of google-antigravity/... as a chat / reasoning endpoint (Cloud Code Assist style). If you set:

{
  tools: {
    byProvider: {
      "google-antigravity": { profile: "minimal" } // or deny:["*"]
    }
  }
}

…then when you’re on either of these:

  • google-antigravity/claude-opus-4-6-thinking
#
  • google-antigravity/claude-opus-4-5-thinking

OpenClaw will still use them for normal conversation output (planning, debugging, writing, analysis), but it won’t try to send tool schemas (so: no read/write/edit/exec/browser/...).

How to use them day-to-day in OpenClaw

Option A (simplest): use them for “thinking”, then switch models when you need tools/files

In chat:

  • Use Antigravity Opus for reasoning:
    /model google-antigravity/claude-opus-4-6-thinking
  • When you actually need file/tool access, switch to a provider that supports OpenClaw’s tool schemas (e.g. an Anthropic/OpenAI model you already have configured):
    /model <your tool-capable model>

Docs: https://docs.openclaw.ai/help/faq (see the /model section) and https://docs.openclaw.ai/tools/slash-commands

This ends up being a nice workflow: