#no response in chat

1 messages · Page 1 of 1 (latest)

tepid dockBOT Feb 15, 2026, 2:18 PM

Setting a Gemini API key in openclaw doctor only covers the model auth part — if you get zero replies, it’s usually one of: gateway not running, Discord channel not connected, pairing/allowlist blocking, or (very common on Discord) mention-gating.

1) Quick Discord-specific checks

If you’re typing in a Discord server channel: try sending a message that mentions the bot (Discord guild messages are mention-gated by default). Docs: https://docs.openclaw.ai/channels/discord (see “Mentions and group DMs”)
If you’re DMing the bot: DMs default to pairing mode, so you may need to approve your DM first:
```
openclaw pairing list discord
openclaw pairing approve discord <CODE>
```
Docs: https://docs.openclaw.ai/channels/pairing

2) Please run these on the machine where the Gateway runs, and paste output

(These usually make the problem obvious.)

openclaw --version
openclaw status --all

openclaw gateway status
openclaw channels status --probe
openclaw logs --follow

Then send one test message in Discord while openclaw logs --follow is running and paste the relevant log lines (look for things like “mention required”, “pairing request”, “blocked/allowlist”, auth errors, etc.).

Troubleshooting ladder (same commands) is here: https://docs.openclaw.ai/help/troubleshooting

3) One clarifying question

Where exactly are you typing “in the chat” — Discord DM, Discord server channel, or the Control UI / web chat?

If you’re talking to it via the localhost Control UI / WebChat, the Discord mention/pairing stuff doesn’t apply — this is almost always one of:

the UI is not actually connected/auth’d to the Gateway WS, or
the Gateway is connected but the model can’t run (wrong default model / missing auth).

From your output the important bit is:

RPC probe: ok ✅ → something is listening on 127.0.0.1:18789
Runtime: unknown (systemctl --user unavailable...) → just means no systemd user service in your environment (WSL/container/etc). That’s not fatal, but it usually means you must run the gateway manually (openclaw gateway run).

Quick test inside the WebChat tab

In the chat UI, send these as standalone messages:

/status
- If this does not respond, the UI isn’t connected/auth’d correctly.
/model status

This will show what model/provider it’s trying to use + whether auth is missing.

If you specifically want Gemini, try: /model gemini-flash (or /model gemini)

CLI checks (paste outputs)

Run (use npx openclaw ... if that’s how you’re running it):

openclaw status --all
openclaw models status
openclaw logs --follow

Then send one message in WebChat while logs --follow is running and paste the log lines that appear (common signatures are “Missing auth”, “No API key found for provider …”, “Model is not allowed”, etc.).

Also: make sure you opened the right UI

Use:

openclaw dashboard

and open the URL it prints (this avoids the “dashboard open without the right token” situation).

If you tell me what /status and /model status return in the WebChat UI, we can usually fix it in one step.

That status --all output is actually good news: your Gateway is reachable on ws://127.0.0.1:18789 and it’s running in token auth mode (“auth token”).

When the Control UI/WebChat shows “no response”, the two most common causes are:

1) Control UI is not connected/auth’d to the Gateway WebSocket

Open http://127.0.0.1:18789/ and check the connection state (usually top bar).

If it says disconnected / unauthorized / 1008, you need to paste your gateway token into the UI once:

Get the token (don’t paste it here):
```
openclaw config get gateway.auth.token
```
In the Control UI, open Settings and paste that token (it’s sent as connect.params.auth.token during the WS handshake).

Docs: https://docs.openclaw.ai/web/control-ui (see “Auth is supplied during the WebSocket handshake…”)

Also try opening via:

openclaw dashboard

(it prints the correct dashboard link + auth hints)

2) The model can’t run (missing/invalid provider auth or wrong model)

Please run and paste:

openclaw models status
openclaw logs --follow

Then send one message in the Control UI while logs --follow is running and paste the error lines that appear.

In the Control UI chat, also try:

/status

/model status
and optionally force Gemini for that session: /model gemini-flash

(If /status doesn’t answer, it’s almost certainly the Control UI connection/auth issue, not Gemini.)

One quick question: are you running OpenClaw inside Docker/WSL or directly on your host? The 172.18.x.x in “Gateway self” often means container networking, and that can affect what “localhost” actually points to.

tepid dockBOT Feb 15, 2026, 3:35 PM

That “Bootstrap: PENDING” line is the giveaway: your main agent hasn’t completed first‑run bootstrapping yet, so the very first time it does respond it should start a short Q&A ritual. Docs: https://docs.openclaw.ai/start/bootstrapping

But if you’re getting no reply at all in the localhost Control UI, the most common reason is: the page loads, but the WebSocket chat connection isn’t authenticated.

1) Fix Control UI auth (token)

Your status --all shows: Gateway … auth token → the UI must send the token.

Run (don’t paste token here):

openclaw dashboard

Open the URL it prints. If the UI still says unauthorized/disconnected, grab the token and paste it into the Control UI Settings:

openclaw config get gateway.auth.token

FAQ section (exact symptom): https://docs.openclaw.ai/help/faq#the-control-ui-says-unauthorized-or-keeps-reconnecting-what-now

2) If UI is connected but still no model replies

Paste these outputs:

openclaw models status
openclaw logs --follow

Then send one message in the Control UI while logs --follow is running and paste the error lines (usually “No API key found…”, “Model is not allowed…”, etc.).

Also: how are you starting the gateway process? In environments without systemd, you typically want:

openclaw gateway run

(and keep that terminal running).

Those log lines mean the important part is working: the Control UI message reached the Gateway and an agent run completed (embedded run done … aborted=false). So “no response” is now almost certainly either:

the reply is being generated but failing (model/auth error), or
the reply was generated but the UI didn’t render/receive the streamed events.

Let’s pin it down fast:

A) Check model/auth on the gateway

Please paste:

openclaw models status

(If Gemini auth didn’t actually load on the gateway host, this will show “Missing auth” / no usable models.)

B) Grab the error (or final reply) for that specific runId from the log file

Your gateway status showed the file log path. Run:

grep -n "35a2dc50-bf2c-4900-9248-be86d5381d20" /tmp/openclaw/openclaw-2026-02-15.log | head -50
grep -n "b03e7b77-5a88-4878-9918-4fc24426763b" /tmp/openclaw/openclaw-2026-02-15.log | head -50

and paste what you get. That usually includes the actual failure reason (or the assistant output size, etc.).

C) One UI sanity check

In the Control UI chat, send /status.

If /status doesn’t answer → the UI isn’t properly connected/auth’d (token/localStorage issue).
If /status answers but normal messages don’t → it’s model/auth or bootstrapping flow.

Also note: your agent shows Bootstrap: PENDING. On first run it should start a short Q&A “bootstrapping ritual”; replies may look like setup questions until that’s completed. Docs: https://docs.openclaw.ai/start/bootstrapping

Two things jump out:

0) You pasted your Gemini API key in public

That AIzaSy... is a real key. Assume it’s compromised and rotate/revoke it now in Google AI Studio / Google Cloud, then re-run openclaw doctor (or set the new GEMINI_API_KEY) on the gateway host.

1) Your model auth looks fine — the agent is actually running

openclaw models status shows:

default model: google/gemini-3-pro-preview
google provider has api_key=1

And your logs show an agent turn finished:

embedded run done … aborted=false

So the problem is now: where did the reply go? (UI not receiving/rendering it, or the run ended with an error before producing an assistant message.)

Fastest way to isolate UI vs agent

Run the TUI (it bypasses the browser UI completely):

openclaw tui

Type hello and press Enter.

If the TUI shows replies → your Gateway + Gemini are fine, and this is Control UI/WebChat rendering/auth/localStorage.
If the TUI also shows no reply → it’s a gateway/model error, and we’ll catch it in logs.

Get the actual error/details for that runId

Your gateway status showed the log file path. Grep the run:

grep -n "35a2dc50-bf2c-4900-9248-be86d5381d20" /tmp/openclaw/openclaw-2026-02-15.log | head -80

Paste those lines (redact secrets). That will usually include the real failure reason.

Also: your agent list earlier showed Bootstrap: PENDING — on first successful reply, the bot should start asking the bootstrapping Q&A questions. Docs: https://docs.openclaw.ai/start/bootstrapping

tepid dockBOT Feb 16, 2026, 12:38 AM

Good, that confirms it’s not a Discord/UI issue anymore:

TUI says connected | idle but you get no assistant message after hello
earlier logs showed embedded run done … aborted=false

That almost always means: the run finishes, but the model call failed, and the error is only visible in the gateway logs.

1) First: revoke/rotate that Gemini key

You pasted an AIza… key publicly. Rotate it now in Google, then update OpenClaw (doctor or config). Assume it’s burned.

2) Grab the actual error from the gateway log

Run this and paste the output (it’s safe as long as you redact keys):

tail -n 200 /tmp/openclaw/openclaw-2026-02-15.log | grep -iE "error|exception|google|gemini|429|403|401|quota|permission|denied|invalid|not found"

If that’s empty, then do:

openclaw logs --follow

Send hello again in the TUI, then paste the new log lines that appear (they’ll include the new runId= and the provider error).

3) Quick model sanity test (in the TUI)

Sometimes the “pro preview” id isn’t enabled for a given key. In the TUI, run:

/model gemini-flash

then send hello again.

Once you paste the log error (403/404/quota/etc.), I can tell you the exact fix in one step.

Those lines you’re seeing are not your “hello” message — they’re heartbeat runs:

messageChannel=heartbeat

So your grep is only catching “run start” lines (because they contain google/gemini) but not the actual failure, and likely not the run from the TUI/WebChat at all.

1) Prove the TUI is actually sending messages

In the TUI, type this and press Enter:

/status

You should get a status block back. If even /status prints nothing, then the TUI isn’t successfully sending/receiving chat events (even though it says connected).

2) Capture the logs live for your message

Run this in a separate terminal:

openclaw logs --follow

Then, in the TUI, send hello again.

Now paste the new log chunk that appears right after you send it — we’re looking for either:

messageChannel=webchat or messageChannel=tui
and any error line right after (quota/403/404/etc.)

3) If you prefer grepping the file: search for actual ERROR/WARN lines

This often instantly shows the Gemini failure:

grep -n '"logLevelName":"ERROR"' /tmp/openclaw/openclaw-2026-02-15.log | tail -50
grep -n '"logLevelName":"WARN"'  /tmp/openclaw/openclaw-2026-02-15.log | tail -50

4) Also: rotate that Gemini key

You posted an AIza… key earlier; assume it’s compromised and revoke/rotate it.

Once you paste either the /status output (from TUI) or the live log chunk from openclaw logs --follow, we’ll know if it’s (a) UI not sending, or (b) Gemini request failing, and the exact fix.

That error blob is the root cause: Gemini is rejecting requests due to free‑tier quota / rate limits (the log even includes RetryInfo: 18s and free-tier quota metrics for gemini-3-pro). When that happens, the agent run ends without producing a normal assistant message, so the UI/TUI looks like “no response”.

Also notice earlier logs said messageChannel=heartbeat — your 30m heartbeat is continuously spending Gemini free-tier quota in the background, even when you’re not chatting.

Fix (fast)

1) Disable heartbeat (so it stops burning quota)

openclaw config set agents.defaults.heartbeat.every "0m"

Then restart the gateway (in Docker/container: restart the container, or stop/start the foreground openclaw gateway run process).

Docs: https://docs.openclaw.ai/gateway/heartbeat (0m disables)

2) Switch to Flash (usually much easier on quotas)

In the TUI (or Control UI chat), run:

/model gemini-flash

(That maps to google/gemini-3-flash-preview.)

Or make it the default:

openclaw config set agents.defaults.model.primary "google/gemini-3-flash-preview"

Restart gateway after changing defaults.

If you want to keep using Pro

You’ll need to add billing / request higher quota on the Google side, or wait for the quota window to reset.

Security note

You pasted an AIza… key earlier in public—please revoke/rotate it in Google AI Studio / Google Cloud and update OpenClaw with the new key.

That error means you have a model allowlist configured (agents.defaults.models), and it currently does not include the Flash model — so /model refuses to switch.

Check what your allowlist is right now

openclaw config get agents.defaults.models

Fix option A (easiest): use the configure wizard to add Flash to the allowlist

openclaw configure --section models

In that “Models” section, make sure google/gemini-3-flash-preview is selected/allowed (along with whatever else you want), save, then restart the gateway process (restart container or stop/start openclaw gateway run).

Fix option B: remove the allowlist entirely (so any discovered model can be selected)

openclaw config unset agents.defaults.models

Then restart the gateway process, and try again:

/model gemini-flash

Docs reference for this exact error: https://docs.openclaw.ai/help/faq (search for “Model is not allowed”)

Also: since you’re hitting free-tier quota, I’d keep your earlier fix in place too:

openclaw config set agents.defaults.heartbeat.every "0m"

(heartbeats can silently burn through Gemini quota in the background).

Create the new key in Google AI Studio, then set it on the machine/container where the Gateway runs.

Where to set the new Gemini key (OpenClaw side)

Best path is the models auth flow:

openclaw models auth add

pick provider google
paste the new API key (don’t paste it in Discord)
then verify:

openclaw models status

After changing auth, restart the gateway (or restart the container / re-run openclaw gateway run).

Alternative (also valid, especially in Docker): set an env var and restart the gateway/container:

GEMINI_API_KEY=...

(OpenClaw resolves Gemini keys from auth profiles, env vars like GEMINI_API_KEY, or models.providers.google.apiKey.)

Important: new key won’t “fix quota” if it’s the same Google project

Your quota error was per project per model (free tier), so rotating the key for the same project usually does not reset limits — you’ll need to wait for the quota window to reset or enable billing / raise quota.

Also: you leaked an AIza… key earlier — revoke/rotate that key in Google ASAP.

No — WhatsApp chatting does not require you to keep an SSH connection open.

What matters is that the Gateway process stays running (because WhatsApp messages go: WhatsApp → Gateway → model → WhatsApp).

You only need SSH for operator access, e.g.:

opening the Control UI/WebChat on a remote machine (SSH tunnel), or
running CLI commands against a remote gateway.

The one exception

If you started the Gateway in the foreground inside your SSH session (e.g. you ran openclaw gateway run in that terminal), then closing SSH will usually stop the Gateway → and then WhatsApp won’t reply.

1) Create a Telegram bot token

In Telegram, chat with @BotFather → run /newbot → copy the token.

(Do not paste the token into Discord.)

2) Add Telegram to your OpenClaw config

Edit ~/.openclaw/openclaw.json (or use openclaw configure) and add:

{
  channels: {
    telegram: {
      enabled: true,
      botToken: "123:abc",     // from BotFather

      dmPolicy: "pairing",     // default, recommended
      groups: { "*": { requireMention: true } },
    },
  },
}

Alternative: you can also set TELEGRAM_BOT_TOKEN=... (default account), but config is clearer.

3) Restart the gateway, then approve your DM pairing

Start/restart the gateway, then DM your bot once in Telegram, then on the gateway host run:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>