#problemas ayuda

4 messages · Page 1 of 1 (latest)

dense thunder
#

The Diagnosis
Currently, the OpenClaw Gateway is configured to call the google/gemini-2.5-pro model. Upon seeing the google/ prefix, the system activates its Native Plugin (plugins/google) by default.

The API_KEY_INVALID error (Code 400) occurs because the native plugin attempts a direct connection via SDK/REST with a null or inconsistent configuration, completely ignoring the executable script we created in /usr/local/bin/gemini.

The Root Cause
OpenClaw prioritizes its internal plugins over system binaries. Your Python script works in the shell, but the OpenClaw Orchestrator doesn't know it should use that file for requests coming from Telegram.

unborn stratusBOT
#

Yeah, that’s basically the right diagnosis, with one important nuance.

It’s not really “OpenClaw prefers plugins over binaries” in the abstract. It picks the provider from the model ref:

  • google/gemini-2.5-proGoogle API provider, expects GEMINI_API_KEY / GOOGLE_API_KEY
  • google-gemini-cli/gemini-...Gemini CLI backend, runs the local gemini command

So if the model is currently google/gemini-2.5-pro, OpenClaw will not use /usr/local/bin/gemini at all. The API_KEY_INVALID error fits that.

If you want the local CLI/script path, the fix is:

  1. switch the model to google-gemini-cli/...
  2. if needed, pin the command path:
{
#
  agents: {
    defaults: {
      model: { primary: "google-gemini-cli/gemini-2.5-pro" },
      cliBackends: {
        "google-gemini-cli": {
          command: "/usr/local/bin/gemini"
        }
      }
    }
  }
}

Also, current docs say Gemini CLI setup is:

#
openclaw models auth login --provider google-gemini-cli --set-default

And on older versions you may also need:

openclaw plugins enable google

Can you paste these two outputs next:

openclaw --version
openclaw models status