#LLM request timed out. After enable Google search

1 messages · Page 1 of 1 (latest)

fickle laurelBOT
#

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

eager stirrupBOT
#

“LLM request timed out” means the Gateway didn’t get a response from your configured model provider within the timeout (it’s not a Discord-side problem). Since it started right after enabling “Google search”, the most common culprit is: you changed config/env during onboarding, but your Gateway service doesn’t have the same env vars/keys (or the new web search provider is hanging).

1) First: collect the 2 outputs that usually make this obvious

Please paste (they’re safe; --all redacts secrets):

openclaw --version
openclaw status --all

Docs (this exact triage flow): https://docs.openclaw.ai/help/faq#first-60-seconds-if-somethings-broken

2) Quick isolation test (does web search trigger the stall?)

Temporarily disable web search and restart the gateway:

# 
openclaw config set tools.web.search.enabled false
openclaw gateway restart

If timeouts stop immediately, then the issue is in your web search setup (provider/key/network).

Web search docs: https://docs.openclaw.ai/tools/web

3) If you’re running the Gateway as a service: fix missing env vars

If you set keys in your terminal shell (or during onboarding) but the Gateway is running via launchd/systemd, it often won’t inherit them. Put the needed keys into:

  • ~/.openclaw/.env (recommended), or
  • store them in config via openclaw configure --section web

Relevant FAQ: https://docs.openclaw.ai/help/faq#i-started-the-gateway-via-the-service-and-my-env-vars-disappeared-what-now

#

4) If you can, grab the smoking gun from logs

Run this, send one test message, then paste the log chunk around the timeout:

openclaw logs --follow

If you paste openclaw --version + openclaw status --all here, I can tell you which provider is timing out and what to change next.

eager stirrupBOT
#

You’re on OpenClaw 2026.3.8 — good.

From the symptom (“started right after enabling Google search” + now every message times out), the two most common causes are:

  1. Your agent run timeout is set too low, and web search pushes runs over that limit
  2. The Gateway service can’t see the API keys (env vars not loaded in the service), so it’s hanging/retrying until timeout

A) Check your agent timeout (quick fix if it’s low)

Run:

openclaw config get agents.defaults.timeoutSeconds

If it’s something small (like 30/60), set it back to something sane (default is 600s):

# 
openclaw config set agents.defaults.timeoutSeconds 600
openclaw gateway restart

B) Confirm your web search config + provider key

Paste this output:

openclaw config get tools.web.search

(If you chose “Gemini / Google Search grounding”, it needs GEMINI_API_KEY; if Brave, it needs BRAVE_API_KEY or tools.web.search.apiKey.)

Docs: https://docs.openclaw.ai/tools/web

C) Your openclaw status --all paste got cut off

#

Can you re-run and paste the full output inside a code block (…), or attach it as a .txt?

openclaw status --all

That output includes a log tail, and usually shows exactly what is timing out (provider/network/auth).

If you reply with:

  • agents.defaults.timeoutSeconds
  • tools.web.search
  • full openclaw status --all

…I can tell you which of the two cases you’re hitting and the exact config change to fix it.

#

That openclaw status --all snippet is already a big clue:

Agents: 1 total · 1 bootstrapping · 0 active

So your only agent is still in the first‑run bootstrapping ritual (it should finish once and then remove BOOTSTRAP.md). If bootstrapping can’t complete (often because the run times out), you’ll keep hitting failures on every message.

1) Check (and likely increase) the agent runtime timeout

Please run:

openclaw config get agents.defaults.timeoutSeconds

If it’s low (e.g. 30/60/120), bump it back up (default is 600s):

# 
openclaw config set agents.defaults.timeoutSeconds 600
openclaw gateway restart

Then send a message again and see if bootstrapping can finally complete.

2) If it still shows “bootstrapping” after that: check for a stuck BOOTSTRAP.md

Bootstrapping lives in the workspace (default ~/.openclaw/workspace). If BOOTSTRAP.md never gets removed, it will keep trying to bootstrap.

Check:

openclaw config get agents.defaults.workspace
ls -la ~/.openclaw/workspace | rg "BOOTSTRAP\\.md" || true
#

If BOOTSTRAP.md is there and you just want to unstick it, rename it (safer than deleting):

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

Bootstrapping doc: https://docs.openclaw.ai/start/bootstrapping

3) One more thing: your status paste is still incomplete

Can you paste the rest of openclaw status --all (especially the bottom log tail)? That will confirm what is timing out (model call vs something else).

If you reply with:

  • agents.defaults.timeoutSeconds value
  • whether BOOTSTRAP.md exists
  • the remaining status --all tail
#

…I can tell you the exact “next step” without guessing.

#

Nice, this confirms what’s happening:

  • Your main agent shows Bootstrap file: PRESENT
  • So it’s still stuck in the bootstrapping first‑run ritual (and that’s why every chat attempt can end up timing out / failing before you ever get to “normal mode”).

Bootstrapping is supposed to remove BOOTSTRAP.md when it completes: https://docs.openclaw.ai/start/bootstrapping

1) First fix: make sure the run timeout isn’t too low

Please run:

openclaw config get agents.defaults.timeoutSeconds

If it’s low (30/60/120), set it back to something sane (default is 600s) and restart:

# 
openclaw config set agents.defaults.timeoutSeconds 600
openclaw gateway restart

2) If it still won’t finish bootstrapping: find + move aside BOOTSTRAP.md

Check your workspace path:

openclaw config get agents.defaults.workspace

Then look for the file and rename it (safe/reversible):

ls -la ~/.openclaw/workspace | rg "BOOTSTRAP\\.md" || true
# 
mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

After that, openclaw status --all should show Bootstrap file: (not present) and the agent should stop trying to bootstrap.

3) If you want to be extra sure the real timeout source isn’t the model

Paste this too:

openclaw models status

And (most useful) the log tail from openclaw status --all after you trigger one timeout.

If you paste:

#
  • agents.defaults.timeoutSeconds
  • agents.defaults.workspace
  • openclaw models status
    …I can tell you whether this is purely “bootstrapping never completes” or if a specific provider call is hanging underneath.
#

Good — openclaw doctor says the Gateway itself is healthy (and the Tailscale ENOENT is unrelated unless you’re trying to use Tailscale).

The real smoking gun is still in your status --all output:

  • Workspace: /home/leran/.openclaw/workspace (from doctor)
  • Agent main: Bootstrap file = PRESENT (from status)

That means OpenClaw thinks it’s still in first-run bootstrapping, which should only happen once and then remove BOOTSTRAP.md.

Do this (safe + reversible)

  1. Confirm your agent timeout isn’t tiny:
openclaw config get agents.defaults.timeoutSeconds

If it’s low (30/60/120), set it to default 600 and restart:

# 
openclaw config set agents.defaults.timeoutSeconds 600
openclaw gateway restart
  1. If it still keeps bootstrapping / timing out, move the bootstrap file aside:
ls -la /home/leran/.openclaw/workspace
mv /home/leran/.openclaw/workspace/BOOTSTRAP.md /home/leran/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

That forces it out of “bootstrap mode”.

If it still says “LLM request timed out” after that

Then it’s not bootstrapping — it’s your model/provider call hanging. Paste these two and we’ll see exactly which provider/model is timing out:

# 
openclaw models status
openclaw logs --limit 200

(Those won’t leak your keys; and logs/status generally redact secrets.)

graceful zephyr
#

leran@DESKTOP-TBB86NH:~$ openclaw config get agents.defaults.timeoutSeconds

🦞 OpenClaw 2026.3.8 (3caab92) — Welcome to the command line: where dreams compile and confidence segfaults.

Config path not found: agents.defaults.timeoutSeconds

eager stirrupBOT
#

Config path not found: agents.defaults.timeoutSeconds just means you haven’t explicitly set it in your config — OpenClaw will use the default (600s). So this isn’t “timeoutSeconds accidentally set too low”.

That also implies what you’re seeing is: the Gateway is waiting the full runtime window, the model call never successfully returns, and then the run aborts with “LLM request timed out.” (Bootstrapping stays “PRESENT” because it never gets far enough to complete and remove BOOTSTRAP.md.)

Next 2 commands will pinpoint the real cause

  1. Show which model/provider it’s trying to use + whether credentials are loaded:
openclaw models status
  1. Show the actual error trail from the gateway:
openclaw logs --limit 200