Bug type
Crash (process/app exits or hangs)
Summary
Multi-step tool calls using the google-gemini-cli provider (native OAuth) consistently hang for exactly 60 seconds between steps, likely due to silent HTTP 429 rate limits and hardcoded retries. In contrast, using a self-hosted API proxy (cliproxyapi) with the exact same Google account executes the same workflow seamlessly in seconds.
Steps to reproduce
1.Configure OpenClaw to use the default google-gemini-cli provider (which uses native web OAuth).
2.Submit a prompt that strictly requires a multi-step tool-calling chain. For example: "Read openclaw config and .bashrc, then search Wikipedia in the browser and send me a screenshot, do this in one go."
3.Monitor the debug logs. Observe the time gap between embedded run prompt start and embedded run tool start.
4.Notice the severe ~60s hangs during the LLM's thinking phase.
5.Change the provider to a custom API proxy (cliproxyapi) using the EXACT SAME underlying Google account.
6.Re-run the exact same prompt and observe that the hangs disappear entirely.
Expected behavior
The agent should process consecutive tool calls without arbitrary 60-second freezes. If the OAuth web endpoint is actively rate-limiting the requests (HTTP 429) due to the agent's rapid tool-calling loop and large context, the google-gemini-cli adapter should either:
1.Explicitly expose the 429 Too Many Requests or "Rate Limit" warning in the [info] or [debug] logs.
2.Fail gracefully rather than entering a silent, hardcoded exponential backoff (sleep 60s) that makes the user think the OpenClaw process has frozen or deadlocked.
Actual behavior
When using the OAuth provider, the local tool execution is instantaneous (0s), but the LLM network turnaround silently stalls for exactly ~60s or ~44s between steps.
Run 1: google-gemini-cli (OAuth) - Total Time: ~183s
Step 1 (Read file): LLM ~7s -> Tool ~0s
Step 2 (Read file): LLM ~44s (Hang) -> Tool ~0s
Step 3 (Browser search): LLM ~60s (Hang) -> Tool ~1s
Step 4 (Browser screenshot): LLM ~4s -> Tool ~0s
Step 5 (Final reply): LLM ~64s (Hang)
Run 2: Self-hosted Proxy (cliproxyapi with SAME account) - Total Time: ~29s
Step 1 (Read file): LLM ~5s -> Tool ~0s
Step 2 (Read file): LLM ~3s -> Tool ~0s
Step 3 (Browser search): LLM ~5s -> Tool ~0s
Step 4 (Browser screenshot): LLM ~5s -> Tool ~0s
Step 5 (Final reply): LLM ~11s
The identical account performs 6x faster purely by changing the endpoint/adapter, proving the OAuth adapter is silently swallowing rate limits and hanging the agent's event loop.
OpenClaw version
2026.3.2
Operating system
Debian GNU/Linux 12 (bookworm)
Install method
No response
Logs, screenshots, and evidence
Impact and severity
No response
Additional information
No response
Bug type
Crash (process/app exits or hangs)
Summary
Multi-step tool calls using the google-gemini-cli provider (native OAuth) consistently hang for exactly 60 seconds between steps, likely due to silent HTTP 429 rate limits and hardcoded retries. In contrast, using a self-hosted API proxy (cliproxyapi) with the exact same Google account executes the same workflow seamlessly in seconds.
Steps to reproduce
1.Configure OpenClaw to use the default google-gemini-cli provider (which uses native web OAuth).
2.Submit a prompt that strictly requires a multi-step tool-calling chain. For example: "Read openclaw config and .bashrc, then search Wikipedia in the browser and send me a screenshot, do this in one go."
3.Monitor the debug logs. Observe the time gap between embedded run prompt start and embedded run tool start.
4.Notice the severe ~60s hangs during the LLM's thinking phase.
5.Change the provider to a custom API proxy (cliproxyapi) using the EXACT SAME underlying Google account.
6.Re-run the exact same prompt and observe that the hangs disappear entirely.
Expected behavior
The agent should process consecutive tool calls without arbitrary 60-second freezes. If the OAuth web endpoint is actively rate-limiting the requests (HTTP 429) due to the agent's rapid tool-calling loop and large context, the google-gemini-cli adapter should either:
1.Explicitly expose the 429 Too Many Requests or "Rate Limit" warning in the [info] or [debug] logs.
2.Fail gracefully rather than entering a silent, hardcoded exponential backoff (sleep 60s) that makes the user think the OpenClaw process has frozen or deadlocked.
Actual behavior
When using the OAuth provider, the local tool execution is instantaneous (0s), but the LLM network turnaround silently stalls for exactly ~60s or ~44s between steps.
Run 1: google-gemini-cli (OAuth) - Total Time: ~183s
Step 1 (Read file): LLM ~7s -> Tool ~0s
Step 2 (Read file): LLM ~44s (Hang) -> Tool ~0s
Step 3 (Browser search): LLM ~60s (Hang) -> Tool ~1s
Step 4 (Browser screenshot): LLM ~4s -> Tool ~0s
Step 5 (Final reply): LLM ~64s (Hang)
Run 2: Self-hosted Proxy (cliproxyapi with SAME account) - Total Time: ~29s
Step 1 (Read file): LLM ~5s -> Tool ~0s
Step 2 (Read file): LLM ~3s -> Tool ~0s
Step 3 (Browser search): LLM ~5s -> Tool ~0s
Step 4 (Browser screenshot): LLM ~5s -> Tool ~0s
Step 5 (Final reply): LLM ~11s
The identical account performs 6x faster purely by changing the endpoint/adapter, proving the OAuth adapter is silently swallowing rate limits and hanging the agent's event loop.
OpenClaw version
2026.3.2
Operating system
Debian GNU/Linux 12 (bookworm)
Install method
No response
Logs, screenshots, and evidence
Impact and severity
No response
Additional information
No response