google-vertex provider fails with "Cannot convert undefined or null to object" after update to v3.2 | Friends of the Crustacean 🦞🤝 | Page 1

late goblet Mar 3, 2026, 5:26 PM

#

Goal:
Use Google Vertex AI models (e.g., google-vertex/gemini-3-flash-preview) with Application Default Credentials (ADC). This was working before the update.
Error:
All calls to google-vertex models now fail with Cannot convert undefined or null to object.
Config:
The issue occurs on agents configured like this:
{"id": "agent1",
"model": "google-vertex/gemini-2.5-flash"
}

Workaround: Changing the provider to "model": "google/gemini-2.5-flash" (using a standard API key) works perfectly.

Environment:

• OS: Linux (GCP)
• OpenClaw: v2026.3.2
• Node.js: v24.14.0

Log Snippet:

{"subsystem":"agent/embedded","1":"...isError=true error=Cannot convert undefined or null to object",...}

This seems to be a bug in how the new version handles ADC for the Vertex AI provider, as the standard google provider works fine.

Thanks for your help!

round folioBOT Mar 3, 2026, 5:26 PM

#

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

quiet jacinthBOT Mar 3, 2026, 5:30 PM

#

That error text (Cannot convert undefined or null to object) is unfortunately too generic — it usually means something internal ended up doing Object.entries(...)/Object.keys(...) on a missing config/auth object, and the embedded runner only logs the .message (no stack), so we need a bit more signal.

A couple things to try / confirm that commonly regress with Vertex + ADC:

1) Make sure the Gateway process actually sees ADC + project/location

Even if ADC works in your shell, the Gateway running as a service often won’t inherit those env vars.

On the machine running the Gateway, as the same user that runs openclaw gateway:

gcloud auth application-default print-access-token (should succeed)
Ensure these are set for the Gateway process (put them in ~/.openclaw/.env and restart):
- GOOGLE_APPLICATION_CREDENTIALS=/path/to/application_default_credentials.json (if you rely on a file)
- GOOGLE_CLOUD_PROJECT=...
- GOOGLE_CLOUD_LOCATION=us-central1 (or your region)

Then:

#

openclaw gateway restart
openclaw models status

Docs refs:

Model providers (Vertex uses gcloud ADC): https://docs.openclaw.ai/concepts/model-providers
Env loading (service vs shell): https://docs.openclaw.ai/help/environment

2) Quick data to paste here (will narrow it down fast)

Can you paste redacted output of:

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

#

Specifically we want to see what models status thinks about the google-vertex provider (auth detected or not) right before it blows up.

3) If you’re sandboxing (Docker): Vertex ADC usually won’t be there

If the agent is running in a sandboxed container, it may not have:

your ~/.config/gcloud ADC files
GOOGLE_APPLICATION_CREDENTIALS
gcloud binary at all

If that’s your setup, try a quick test with sandboxing off (or run the agent in “main/non-sandbox”) just to confirm whether it’s purely an ADC visibility issue.

If the env/project/location are present and it still fails on 2026.3.2 while google/* works, this smells like a real regression in the google-vertex path. In that case, best next step is a GitHub issue with the three command outputs above + a minimal config snippet (like you shared).

late goblet Mar 3, 2026, 5:46 PM

#

I have also created a ~/.openclaw/.env file with the following content, as you suggested:

GOOGLE_APPLICATION_CREDENTIALS=/home/affan/.config/gcloud/application_default_credentials.json
GOOGLE_CLOUD_PROJECT=project-affan
GOOGLE_CLOUD_LOCATION=global

After creating the file and restarting the gateway, the error still persists.

Here is the requested command output:

openclaw --version
2026.3.2

───

openclaw models status --json
{
"configPath": "/home/affan/.openclaw/openclaw.json",
"defaultModel": "google-vertex/gemini-3-flash-preview",
"auth": {
"providers": [
{
"provider": "google",
"effective": {
"kind": "profiles",
"detail": "~/.openclaw/agents/main/agent/auth-profiles.json"
}
},
{
"provider": "google-vertex",
"effective": {
"kind": "env",
"detail": "<a...d>"
},
"env": {
"value": "<a...d>",
"source": "gcloud adc"
}
}
]
}
}

(Full JSON is very long, this is the most relevant part showing google-vertex auth is detected via gcloud adc)

───

openclaw status --all
🦞 OpenClaw 2026.3.2
...
! Tailscale: off · unknown error: Error: spawn tailscale ENOENT
...
! Channel issues (1) - whatsapp[default] auth: Not linked (no WhatsApp Web session).

(This command also produced very long output. I've included the most relevant warnings. The full output is available if needed.)

───

To confirm, I am not using Docker or any sandboxing. The issue seems to be directly related to the google-vertex provider's interaction with ADC in this new version, as the google provider with an API key works flawlessly.

Let me know if you need any other specific parts of the logs. Thank you!

quiet jacinthBOT Mar 3, 2026, 5:47 PM

#

Good, that models status --json snippet is super useful: it shows OpenClaw is detecting google-vertex auth via “gcloud adc”, so this isn’t the usual “service can’t see env” problem.

Two concrete next steps:

1) Your `GOOGLE_CLOUD_LOCATION=global` is very likely the culprit

For Vertex AI, the location typically needs to be a region (e.g. us-central1, europe-west4, etc.). global is commonly used in other Google contexts, but it’s not a safe/default Vertex GenAI region.

Try this in ~/.openclaw/.env:

GOOGLE_CLOUD_LOCATION=us-central1
# keep your GOOGLE_CLOUD_PROJECT and GOOGLE_APPLICATION_CREDENTIALS as-is

Then:

#

openclaw gateway restart

…and retry a simple prompt.

If that fixes it, we should probably update docs to recommend a real region for Vertex.

2) Get a real error from the provider via `--probe`

Right now we only see the embedded runner’s generic error string. The probe path usually returns a more actionable failure.

Run:

openclaw models status --probe --probe-provider google-vertex --json

#

…and paste just the probe / errors part for google-vertex.

If GOOGLE_CLOUD_LOCATION=us-central1 doesn’t help and the probe still ends up as Cannot convert undefined or null to object, then yeah: that’s almost certainly a regression/bug in the google-vertex provider path in 2026.3.2 (since auth is detected but calls blow up). At that point, the probe output is exactly what we’d want in a GitHub issue.

late goblet Mar 3, 2026, 6:05 PM

#

Hello Krill,

Thank you for the guidance. I've set GOOGLE_CLOUD_LOCATION=us-central1 and restarted the gateway, but the error still persists.

As you requested, I ran the probe command. Here is the most interesting part of the result:

"probes": {
"results": [
{
"provider": "google-vertex",
"model": "google-vertex/gemini-3-flash-preview",
"status": "ok",
"latencyMs": 4757
}
]
}

The probe result shows that the connection to Vertex AI is successful ("status": "ok") and fast. This confirms that my ADC and environment variables are being picked up correctly by the system.

However, when an agent actually tries to use the model in a conversation, it still fails with the Cannot convert undefined or null to object error.

This strongly suggests a regression/bug within the google-vertex provider path in version 2026.3.2, where the probe succeeds but the execution path fails. For now, I will continue using the google provider as a workaround.

quiet jacinthBOT Mar 3, 2026, 6:06 PM

#

Yep — probe = ok is the key new signal here.

openclaw models status --probe is basically a “can I do a minimal request to this provider/model with this auth?” check. A real agent run goes through a different path: it sends the full toolset + tool schemas + extra params, does tool-call parsing, etc.

So the most likely situation now is:

Vertex + ADC is fine (confirmed by probe)
The google-vertex execution path is blowing up when tools are included (schema/function-calling path), and the embedded runner is only surfacing the generic JS error text.

Quick confirmation test: disable tools only for google-vertex

In ~/.openclaw/openclaw.json, add a provider-specific tool restriction:

{
  tools: {
    byProvider: {

#

      "google-vertex": { profile: "minimal" } // effectively “no tools”
    }
  }
}

Restart the gateway, then try a normal conversation again using google-vertex/....

If it suddenly works: it’s 100% a tools/schema/function-calling regression in the google-vertex path (probe wouldn’t catch this).
If it still fails even with tools removed: then it’s deeper than tools (less likely given the probe success).

Docs for this knob: https://docs.openclaw.ai/tools (see “Provider-specific tool policy”).

Next step (so it actually gets fixed)

Please file a GitHub bug with these bullets — it’s a very actionable report:

#

OpenClaw 2026.3.2, Linux (GCP), Node 24.14.0
openclaw models status --probe --probe-provider google-vertex => ok
Normal agent run with google-vertex/... => Cannot convert undefined or null to object
Whether tools.byProvider.google-vertex.profile=minimal makes it work or not

GitHub issues: https://github.com/openclaw/openclaw/issues

If you paste the result of that “tools disabled for vertex” test here, I can help you word the issue in a way that’s hard to ignore/triage incorrectly.

late goblet Mar 3, 2026, 6:16 PM

#

Hello Krill,

I've completed the final test as you suggested.

I added the following to my openclaw.json:

"tools": {
"byProvider": {
"google-vertex": { "profile": "minimal" }
}
}

After restarting the gateway, I ran a test by spawning a sub-agent with a google-vertex model and a simple chat task.

Result: It still fails. The sub-agent process completes internally (I can see its response in the system logs), but it fails to deliver the final message back to the main session, ending with a Subagent main failed error.

This confirms your second theory: the issue is deeper than just function-calling/tools and seems to be a more fundamental regression in the google-vertex execution path for version 2026.3.2.

quiet jacinthBOT Mar 3, 2026, 6:17 PM

#

That’s a really strong datapoint.

Probe succeeds ⇒ ADC + Vertex connectivity + basic request/response is fine.
Tools forced to minimal and it still fails ⇒ not a function-calling/tool-schema conversion issue.
You can see the sub-agent’s response in logs but it fails to “deliver back” ⇒ this points at the embedded run / streaming → OpenClaw message assembly/delivery path for google-vertex in 2026.3.2 (i.e. the model answered, but something in the wrapper pipeline crashes while turning that into the final message / subagent result).

At this point, the best next step is a GitHub bug with the one missing piece: a stack trace. The thread log line only shows error.message, but the gateway log usually has the actual TypeError with a stack nearby.

What to include in the GitHub issue (to make it actionable)

“Probe OK but embedded run fails”:

openclaw models status --probe --probe-provider google-vertex --json (the probes section you pasted)

Confirmation it’s not tools:

your tools.byProvider.google-vertex.profile = "minimal" test result

The stack trace:

Please grab the chunk from the gateway log file in /tmp/openclaw/openclaw-*.log (or openclaw logs --follow) around the first occurrence of:

#

TypeError: Cannot convert undefined or null to object
- plus ~30 lines before/after (or the full stack)

Minimal config snippet:

the agent model line + your .env vars (project + location + ADC path)

Issue link: https://github.com/openclaw/openclaw/issues
(You can mention that google/* via API key works, google-vertex/* fails only in the embedded execution path on 2026.3.2.)

If you paste the stack trace snippet here first, I can help you pinpoint which file/function is blowing up so the report can say “crashes in X when processing Y” instead of just the generic TypeError.

late goblet Mar 3, 2026, 6:48 PM

#

Hello Krill,

This is the final piece of the puzzle. I've searched the gateway logs (/tmp/openclaw/openclaw-*.log) for the TypeError: Cannot convert undefined or null to object stack trace as you requested.

Result: The stack trace is not present in the logs. The only relevant line is the generic error message itself, without any detailed trace:

{"subsystem":"agent/embedded","1":"...isError=true error=Cannot convert undefined or null to object",...}

I used grep -C 30 "TypeError..." and confirmed that no stack trace is being logged for this specific error.

Conclusion:
This seems to be part of the bug itself. Not only is the google-vertex execution path failing, but the error logging for it is also suppressed in version 2026.3.2, preventing us from getting a detailed stack trace.

This confirms:

Probe is OK.
Run fails even with tools.profile = "minimal".
The failure log is suppressed and does not include a stack trace.

This is all the information I can gather. I will now file a formal GitHub issue with these three key findings. For now, I will stick to the google provider as a stable workaround.

Thank you for your incredible help in debugging this!

quiet jacinthBOT Mar 3, 2026, 6:49 PM

#

That’s enough to file a solid bug — and you’re right: in the current embedded runner path, the stack trace can be effectively “lost” even when it exists.

Two notes that may help your GitHub issue land quickly:

1) The missing stack trace is (mostly) a logging behavior in the embedded path

In OpenClaw, the agent/embedded lifecycle log line you’re seeing is built from the error message only (not err.stack). So it’s very possible the stack exists at the throw site, but the embedded runner intentionally collapses it to .message.

If you want, you can mention this in the issue as “stack suppressed by embedded error reporting”, and point to these files in the repo:

src/agents/pi-embedded-runner/utils.ts → describeUnknownError() returns only error.message
src/agents/pi-embedded-subscribe.handlers.lifecycle.ts → logs error=${errorText} (no stack)

So fixing this may be two bugs:

google-vertex run path throws TypeError
embedded error logging doesn’t include stack, making it hard to diagnose

#google-vertex provider fails with "Cannot convert undefined or null to object" after update to v3.2

1) Make sure the Gateway process actually sees ADC + project/location

2) Quick data to paste here (will narrow it down fast)

3) If you’re sandboxing (Docker): Vertex ADC usually won’t be there

1) Your `GOOGLE_CLOUD_LOCATION=global` is very likely the culprit

2) Get a real error from the provider via `--probe`

Quick confirmation test: disable tools only for google-vertex

Next step (so it actually gets fixed)

What to include in the GitHub issue (to make it actionable)

1) The missing stack trace is (mostly) a logging behavior in the embedded path

2) Your key findings (probe ok, run fails) strongly suggest a post-request failure

#google-vertex provider fails with "Cannot convert undefined or null to object" after update to v3.2

1) Make sure the Gateway process actually sees ADC + project/location

2) Quick data to paste here (will narrow it down fast)

3) If you’re sandboxing (Docker): Vertex ADC usually won’t be there

1) Your GOOGLE_CLOUD_LOCATION=global is very likely the culprit

2) Get a real error from the provider via --probe

Quick confirmation test: disable tools only for google-vertex

Next step (so it actually gets fixed)

What to include in the GitHub issue (to make it actionable)

1) The missing stack trace is (mostly) a logging behavior in the embedded path

2) Your key findings (probe ok, run fails) strongly suggest a post-request failure

1) Your `GOOGLE_CLOUD_LOCATION=global` is very likely the culprit

2) Get a real error from the provider via `--probe`