[BUG] Gemini models in WSL env: Request contains an invalid argument.

[TanteJossa]

Problem (one or two sentences)

When using any gemini model in a project in vscode that is in wsl environment I get the following error. see below for logs.

Context (who is affected and when)

Users of Gemini models in wsl environment

Reproduction steps

1. Computer version info
   WSL version: 2.4.12.0
   Kernel version: 5.15.167.4-1
   WSLg version: 1.0.65
   MSRDC version: 1.2.5716
   Direct3D version: 1.611.1-81528511
   DXCore version: 10.0.26100.1-240331-1435.ge-release
   Windows version: 10.0.26200.8246

2. roo version
   3.53.0

3. vscode version
   Version: 1.117.0 (user setup)
   Commit: 10c8e557c8b9f9ed0a87f61f1c9a44bde731c409
   Date: 2026-04-21T16:12:14-07:00
   Electron: 39.8.7
   ElectronBuildId: 13841579
   Chromium: 142.0.7444.265
   Node.js: 22.22.1
   V8: 14.2.231.22-electron.0
   OS: Windows_NT x64 10.0.26200

4. select gemini model and send a message when vscode is inialized in wsl

Expected result

google accepting request

Actual result

google not accepting request

Variations tried (optional)

No response

App Version

3.53.0

API Provider (optional)

Google Gemini

Model Used (optional)

N/A

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

// Please share this file with Roo Code Support (support@roocode.com) to diagnose the issue faster
// Just make sure you're OK sharing the contents of the conversation below.

{
  "error": {
    "timestamp": "2026-04-26T18:33:49.190Z",
    "version": "3.53.0",
    "provider": "gemini",
    "model": "gemini-3-flash-preview",
    "details": "Gemini generate context stream error: {\"error\":{\"message\":\"{\\n  \\\"error\\\": {\\n    \\\"code\\\": 400,\\n    \\\"message\\\": \\\"Request contains an invalid argument.\\\",\\n    \\\"status\\\": \\\"INVALID_ARGUMENT\\\"\\n  }\\n}\\n\",\"code\":400,\"status\":\"Bad Request\"}}"
  },
  "history": [
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "text": "<user_message>\ntest\n</user_message>"
        },
        {
          "type": "text",
          "text": "<environment_details>\n# VSCode Visible Files\n../../../../tmp/roo-diagnostics-019dcb0f-1777228321009.json\n\n# VSCode Open Tabs\nrole-group-system-design.md,../../../../tmp/roo-diagnostics-019dcb0f-1777228321009.json\n\n# Current Time\nCurrent time in ISO 8601 UTC format: 2026-04-26T18:33:45.591Z\nUser time zone: Europe/Leiden, UTC+2:00\n\n# Current Cost\n$0.00\n\n# Current Mode\n<slug>ask</slug>\n<name>❓ Ask</name>\n<model>gemini-3-flash-preview</model>\n\n\n# Current Workspace Directory (/home/user/code/project) Files\n\n(File list truncated. Use list_files on specific subdirectories if you need to explore further.)\nYou have not created a todo list yet. Create one with `update_todo_list` if your task is complicated or involves multiple steps.\n</environment_details>"
        }
      ],
      "ts": 1777228425642
    }
  ]
}

[roomote-v0]

I'd like to help with this issue, but I need some clarification to narrow down the root cause. After reviewing the codebase, the Gemini provider code (src/api/providers/gemini.ts) doesn't have any WSL-specific code paths -- the request construction is identical regardless of the OS environment.

The 400 INVALID_ARGUMENT error from Google's API is unfortunately very generic and doesn't specify which argument is invalid. A few questions to help isolate the problem:

1. Have you tested the same API key outside of WSL? For example, does it work when you open VS Code natively on Windows (not through Remote-WSL) with the same Gemini API key and the same model?

2. Which specific Gemini models have you tested? The error log shows gemini-3-flash-preview -- have you also tried gemini-2.5-pro, gemini-2.5-flash, or other non-preview models?

3. What type of API key are you using? Is it a free tier Google AI Studio key, or a paid/billing-enabled key? Some preview models have restricted access.

4. Do you have a custom base URL configured? Check if you have a googleGeminiBaseUrl set in your Roo Code settings -- a misconfigured base URL could cause this error.

5. Can you test a raw API call from WSL? Running this from your WSL terminal would help isolate whether the issue is with the API key/model access or with Roo Code specifically:

   curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent?key=YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"contents":[{"parts":[{"text":"Hello"}]}]}'

6. Is there a proxy or firewall in your WSL environment? Some corporate network configurations can modify HTTP requests in transit, potentially causing validation errors on the server side.

Please tag @roomote in your response with the answers, and I'll be happy to continue investigating.

[TanteJossa]

@roomote

1. api works everywhere else
2. same issue for every model
3. using tier 3 paid key, through ai studio, works everywhere else
4. no custom base url
5. . this returns correctly
   {
   "candidates": [
   {
   "content": {
   "parts": [
   {
   "text": "Hello! How can I help you today?"
   }
   ],
   "role": "model"
   },
   "finishReason": "STOP",
   "index": 0
   }
   ],
   "usageMetadata": {
   "promptTokenCount": 1,
   "candidatesTokenCount": 9,
   "totalTokenCount": 169,
   "promptTokensDetails": [
   {
   "modality": "TEXT",
   "tokenCount": 1
   }
   ],
   "thoughtsTokenCount": 159
   },
   "modelVersion": "gemini-2.5-flash",
   "responseId": "b77vadOkN6e0vd8iIwAk"
   }
6. it worked last week, and i havent changed anything about the installation and there is no firewall

I think there could be 2 options:

1. the Google api became stricter, so it doesnt accept a certain key send by the roocode request
2. Roocode send a new invalid key which causes the request to fail

[TanteJossa]

@roomote

[roomote-v0]

I've seen your follow-up and will explore a potential fix. The 400 INVALID_ARGUMENT error is likely caused by tool parameter schemas containing type: ["string", "null"] (JSON Schema nullable syntax) that the Gemini API may not fully support in parametersJsonSchema. Multiple tool definitions use this pattern. I'll open a PR with a schema sanitization layer for Gemini that converts these to a format the API accepts. I'll share progress shortly.

[roomote-v0]

Opened a draft PR with my attempt at addressing this: #12221

The fix adds schema sanitization for Gemini tool parameter declarations, converting type: ["string", "null"] to type: "string", nullable: true and removing additionalProperties -- both are JSON Schema constructs that the Gemini API may reject. Multiple tool definitions use these patterns.

Feedback welcome!