Description
In the latest stable version (v2026.3.2, build 85377a2) running on Windows 11 (10.0.26200, x64), images received from Telegram are silently discarded when routed to a model configured with the native google-generative-ai API adapter.
The same images work flawlessly when using the openai-completions adapter pointing to the exact same backend model and endpoint.
Steps to Reproduce
- Configure two providers in
openclaw.json:
- Provider A:
api: "google-generative-ai" (native Gemini SDK, /v1beta)
- Provider B:
api: "openai-completions" (OpenAI-compatible, /v1)
- Both pointing to the same backend model (e.g.
gemini-3.1-pro)
- Send an image via Telegram to the agent
- Switch the agent's model between Provider A and Provider B
Expected Behavior
Both adapters should include the image payload in the API request, and the model should describe/process the image.
Actual Behavior
- Provider B (
openai-completions): Image is included correctly. Model sees and describes the image. ✅
- Provider A (
google-generative-ai): Image payload is silently dropped. Model responds as if no image was sent, or says it cannot see any image. ❌
No error is logged. The image simply disappears from the request payload.
Likely Cause
This closely resembles a regression of the previously resolved #25878 (SafeOpenError — stat.dev vs lstat.dev returning 0 on Windows in fs-safe.ts / openVerifiedLocalFile()).
The native google-generative-ai adapter likely reads the file from disk via openVerifiedLocalFile(), which fails the path verification on Windows. The openai-completions adapter presumably uses a different code path (base64 inline or URL reference) that bypasses this check entirely.
Relevant source files:
src/fs-safe.ts (openVerifiedLocalFile)src/agents/pi-embedded-helpers/images.ts (sanitizeSessionMessagesImages)src/agents/tool-images.ts (sanitizeContentBlocksImages)
Environment
Workaround
Use openai-completions adapter instead of google-generative-ai for image-related tasks on Windows.
Description
In the latest stable version (v2026.3.2, build
85377a2) running on Windows 11 (10.0.26200, x64), images received from Telegram are silently discarded when routed to a model configured with the nativegoogle-generative-aiAPI adapter.The same images work flawlessly when using the
openai-completionsadapter pointing to the exact same backend model and endpoint.Steps to Reproduce
openclaw.json:api: "google-generative-ai"(native Gemini SDK,/v1beta)api: "openai-completions"(OpenAI-compatible,/v1)gemini-3.1-pro)Expected Behavior
Both adapters should include the image payload in the API request, and the model should describe/process the image.
Actual Behavior
openai-completions): Image is included correctly. Model sees and describes the image. ✅google-generative-ai): Image payload is silently dropped. Model responds as if no image was sent, or says it cannot see any image. ❌No error is logged. The image simply disappears from the request payload.
Likely Cause
This closely resembles a regression of the previously resolved #25878 (
SafeOpenError—stat.devvslstat.devreturning0on Windows infs-safe.ts/openVerifiedLocalFile()).The native
google-generative-aiadapter likely reads the file from disk viaopenVerifiedLocalFile(), which fails the path verification on Windows. Theopenai-completionsadapter presumably uses a different code path (base64 inline or URL reference) that bypasses this check entirely.Relevant source files:
src/fs-safe.ts(openVerifiedLocalFile)src/agents/pi-embedded-helpers/images.ts(sanitizeSessionMessagesImages)src/agents/tool-images.ts(sanitizeContentBlocksImages)Environment
Workaround
Use
openai-completionsadapter instead ofgoogle-generative-aifor image-related tasks on Windows.