Im trying to interact with my agent but i keep getting this error evenafter killing verything restar | Friends of the Crustacean 🦞🤝 | Page 1

viral pagoda Apr 16, 2026, 9:11 PM

#

⚠️ Agent couldn't generate a response. Please try again.

when i run
"openclaw logs --follow
"

21:06:18+00:00 info web-heartbeat {"module":"web-heartbeat","runId":"70cd4275-0304-4b60-a584-8fe3ad4c97b3"} {"connectionId":"c5a72eae-097a-4c2c-9499-ea2d0a8e48ec","reconnectAttempts":0,"messagesHandled":1,"lastInboundAt":1776373523084,"authAgeMs":123978.71801757812,"uptimeMs":123968} web gateway heartbeat
21:06:27+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=d0ba8050-f510-430d-a339-dba6977c36f8 sessionId=d0ba8050-f510-430d-a339-dba6977c36f8 stopReason=stop payloads=0 — surfacing error to user

arctic anvilBOT Apr 16, 2026, 9:11 PM

#

night reefBOT Apr 16, 2026, 9:11 PM

#

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

arctic anvilBOT Apr 16, 2026, 9:11 PM

#

gloomy pecanBOT Apr 16, 2026, 9:13 PM

#

I’m checking the exact code path for that warning so I can tell you whether this is a model/provider issue, a session-store issue, or something else.

#

I found the exact code path for your warning. It’s the generic “the model finished the turn but produced no visible output” path, not a gateway crash. I’m checking the docs for the fastest commands to narrow down which kind of empty response it is.

#

The web-heartbeat line is normal. The important line is:

incomplete turn detected ... stopReason=stop payloads=0

That means the agent run ended with no user-visible reply, so OpenClaw showed the generic fallback. Usually this is a model/provider/session problem, not the heartbeat itself.

First, please paste:

openclaw --version

Then run:

openclaw status --all

#

openclaw models status
openclaw doctor

Then reproduce it once and paste 30 to 50 log lines before the warning, not just the final 2 lines. The real cause is usually a little earlier in the log.

Two quick clues:

If /new or a brand new thread works, it is probably a stale/bad session.
If nothing works anywhere, I’d suspect model/auth/provider compatibility first.
If you’re using Ollama, LM Studio, or another OpenAI-compatible local backend, say that too, because there’s a separate troubleshooting path for those.

Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/gateway/troubleshooting

viral pagoda Apr 16, 2026, 9:18 PM

#

joe@DESKTOP-6DBBKUB:~$ openclaw --version
OpenClaw 2026.4.14 (323493f)

#

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/joe/.openclaw/openclaw.json
Bind: loopback

✓ Config: /home/joe/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 11824 joe: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: off · unknown
✓ Skills: 12 eligible · 0 missing · /home/joe/.openclaw/workspace
✓ Plugin compatibility (none)
✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

◇
joe@DESKTOP-6D

gloomy pecanBOT Apr 16, 2026, 9:18 PM

#

Nice, that version is recent, so this is probably not just "update and retry."

Also, 2026.4.14 already includes retry logic for this exact class of failure. So if you still end up at:

incomplete turn detected ... stopReason=stop payloads=0

it usually means the model/backend is repeatedly returning no visible answer.

Next, please paste these:

openclaw status --all
openclaw models status
openclaw doctor

And when you reproduce it again, grab 20 to 40 log lines before the final warning. In your version, I specifically want to see whether there are lines like:

#

reasoning-only assistant turn detected
empty response detected

Those usually appear right before the final fallback.

Also tell me which backend you’re using:

hosted provider, or
local/OpenAI-compatible backend like Ollama, LM Studio, vLLM, etc.

One quick isolation test too:

If /new or a brand new thread works, this is probably a stale session.
If every new session fails, I’d look at the model/provider/backend first.

Troubleshooting doc: https://docs.openclaw.ai/gateway/troubleshooting

#

This helps. Your gateway is already running, so the Port 18789 is already in use bit is not the bug here. Don’t stop it just because of that line.

So far we’ve ruled out “gateway isn’t up.” The next thing to check is the model/backend layer.

Please paste:

openclaw models status
openclaw doctor

And then reproduce the failure once more and scroll a little above the final warning in the logs. On your version I’m specifically looking for one of these lines right before it:

reasoning-only assistant turn detected
empty response detected

Those tell us whether the model is returning hidden reasoning only, or just an empty reply.

#

Also, are you using:

a hosted provider, or
a local backend like Ollama / LM Studio / vLLM?

One quick test too:

try /new
then send a super simple message like hi

If the new session also fails, I’d blame the model/backend first. If only the old session fails, it is probably a stale session issue.

viral pagoda Apr 16, 2026, 9:19 PM

#

openclaw doctor

🦞 OpenClaw 2026.4.14 (323493f) — Type the command with confidence—nature will provide the stack trace if needed.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openrouter/openai/gpt-4o-mini
Fallbacks (2) : google/gemini-2.0-flash, openrouter/x-ai/grok-4.1-fast
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (4): openrouter/openai/gpt-4o-mini, google/gemini-2.0-flash, openrouter/x-ai/grok-4.1-fast, openrouter/openrouter/auto

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...807b0941

Missing auth

google Run openclaw models auth login --provider google, openclaw configure, or set an API key env var.

OAuth/token status

none

🦞 OpenClaw 2026.4.14 (323493f) — I'm the middleware between your ambition and your attention span.

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
██░▄▄▄░██░▄▄░██░▄▄▄██░▀██░██░▄▄▀██░████░▄▄▀██░███░██
██░███░██░▀▀░██░▄▄▄██░█░█░██░█████░████░▀▀░██░█░█░██
██░▀▀▀░██░█████░▀▀▀██░██▄░██░▀▀▄██░▀▀░█░██░██▄▀▄▀▄██
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
🦞 OPENCLAW 🦞

┌ OpenClaw doct

#

│
│ Fix (pick one): │
│ - Set OPENAI_API_KEY, GEMINI_API_KEY, GOOGLE_API_KEY, VOYAGE_API_KEY, MISTRAL_API_KEY in │
│ your environment │
│ - Configure credentials: openclaw configure --section model │
│ - For local embeddings: configure agents.defaults.memorySearch.provider and local model │
│ path │
│ - To disable: openclaw config set agents.defaults.memorySearch.enabled false │
│ │
│ Verify: openclaw memory status --deep

gloomy pecanBOT Apr 16, 2026, 9:20 PM

#

Nice, this narrows it down a lot.

What we know now:

the gateway is up
your primary OpenRouter auth exists
your Google fallback is missing auth

That missing Google auth is worth fixing, but it should not by itself break every turn if the primary model is healthy.

Next I’d isolate provider/model vs session/chat with these two commands:

openclaw models status --probe
openclaw infer model run --model openrouter/openai/gpt-4o-mini --prompt "Reply with just: hi" --json

#

Please paste both outputs.

How to read that test:

If the direct infer model run fails, the problem is in the provider/model path.
If the direct infer model run works, the model path is fine and I’d look at the session/thread state next.

If the direct run works, do this after:

/new
send hi

Also, when you reproduce the failure in chat, please paste the log chunk above the final warning. I’m still looking for one of these lines right before it:

reasoning-only assistant turn detected
empty response detected

#

One small cleanup for later: either authenticate Google, or remove that Google fallback for now, so failover is not half-broken.

#

That’s a useful clue. I’m checking the memory-search docs so I can give you the exact fix path, not a guess.

#

Yep, this is the first real smoking gun.

Your chat model is using OpenRouter, but memory search is a separate subsystem and it needs its own embedding provider. OpenRouter auth for chat does not satisfy that.

So the likely failure path is:

agent turn starts
memory search / active memory tries to run
embeddings are unavailable
the turn falls through into that generic incomplete turn error

Fastest unblock

If you just want the agent replying again, disable memory search for now:

openclaw config set agents.defaults.memorySearch.enabled false

#

openclaw gateway restart
openclaw memory status --deep

Then test again with:

/new
hi

If you want memory search to stay on

Configure an embedding provider for memorySearch, for example:

OpenAI
Gemini
Voyage
Mistral

#

local
Ollama

Docs:
https://docs.openclaw.ai/reference/memory-config
https://docs.openclaw.ai/cli/memory

My recommendation: disable memory search first, make sure replies work again, then re-enable it once embeddings are configured.

viral pagoda Apr 17, 2026, 10:17 AM

#

reading to:

⚠️ Agent couldn't generate a response. Please try again.

#

scopesTo=operator.admin,operator .approvals,operator.pairing,oper ator.read,operator.talk.secrets, operator.write client=cli
conn=d91493fc-f145-4bc0-b30a-9778c9813257
10:09:13+00:00 error gateway connect failed: GatewayClientRequestError: pairing required
10:09:13+00:00 error gateway connect failed: GatewayClientRequestError: pairing required
gateway connect failed: GatewayClientRequestError: pairing required
10:09:13+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"pairing-required","handshake":"failed","durationMs":41,"last
...(truncated)...

gloomy pecanBOT Apr 17, 2026, 10:18 AM

#

I’m checking the active-memory docs too, because if memorySearch.enabled false didn’t unblock it, the separate active-memory plugin may still be in play.

#

If you’re still getting the same error after the memory-search change, then memory search was not the whole story.

There’s a second layer here: Active Memory is configured separately from memorySearch.

Docs split it like this:

agents.defaults.memorySearch.*
plugins.entries.active-memory.*
plugins.slots.memory lets you disable memory plugins entirely

Fastest next isolation step

Temporarily disable the memory plugin slot completely:

openclaw config set plugins.slots.memory none
openclaw gateway restart

#

Then test again with:

/new
hi

Before or after that, please paste these too

openclaw config get agents.defaults.memorySearch
openclaw config get plugins.entries.active-memory
openclaw config get plugins.slots.memory
openclaw memory status --deep

If disabling plugins.slots.memory fixes it, then we know the failure is definitely in the memory plugin path, and we can re-enable it piece by piece.

If it still fails after that, I want the next two things:

#

openclaw models status --probe

and the log lines above the final incomplete turn detected warning.

Docs:
https://docs.openclaw.ai/concepts/active-memory
https://docs.openclaw.ai/reference/memory-config

#

I think we finally hit the real auth problem. I’m pulling the exact device-pairing docs so I can give you the right recovery steps.

#

Ah, this is important.

GatewayClientRequestError: pairing required means your CLI itself is not approved for the gateway role/scopes it’s asking for yet.

So I’d fix this first, before chasing the incomplete turn any further.

Do this

openclaw devices list

Find the pending request for the CLI, then approve it with the exact request ID:

openclaw devices approve <requestId>

#

A couple gotchas from the docs:

run openclaw devices list right before approval, because the request ID can change if the client retries
openclaw devices approve --latest only previews the newest request, it does not fully approve it

Then rerun

openclaw models status --probe
openclaw doctor

And test again with:

/new
hi

If it still fails after the device is approved, paste:

#

the output of openclaw devices list
the exact devices approve ... result
the next log chunk around the failure

Docs:
https://docs.openclaw.ai/cli/devices
https://docs.openclaw.ai/gateway/troubleshooting

viral pagoda Apr 17, 2026, 10:24 AM

#

10:22:57+00:00 info Approved c793c9b9a167a3f7d87d51d2bb4b9ea2de93bc3b4a30180994ffaede25e788fa (abaf20bb-bf24-4194-9901-ec5ccb77c04f)
10:23:30+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=8b2c5fd6-b365-4a5e-a207-8566c370deb3 sessionId=0769bb71-98f9-4018-a689-7aa01238d4e3 stopReason=stop payloads=0 — surfacing error to user
10:23:35+00:00 info web-heartbeat {"module":"web-heartbeat","runId":"3c1e1ecc-68ce-4b1d-bcdd-f503572d38d0"} {"connectionId":"37913736-1009-4719-89c5-f560436bd59b","reconnectAttempts":0,"messagesHandled":1,"lastInboundAt":1776420561103,"authAgeMs":343287.7497558594,"uptimeMs":942419} web gateway heartbeat
10:24:19+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=1da8e74b-3468-4087-ae95-b1f88923d195 sessionId=0769bb71-98f9-4018-a689-7aa01238d4e3 stopReason=stop payloads=0 — surfacing error to user

gloomy pecanBOT Apr 17, 2026, 10:25 AM

#

Good, the Approved ... line means the pairing issue is fixed. So this remaining failure is a separate problem.

Also, both failing runs are using the same sessionId:

0769bb71-98f9-4018-a689-7aa01238d4e3

So the next step is really important:

1) Force a fresh chat session

In the chat, run:

/new

Then send:

#

hi

2) Test the model directly from CLI

Now that pairing is fixed, run:

openclaw models status --probe
openclaw infer model run --model openrouter/openai/gpt-4o-mini --prompt "Reply with just: hi" --json

What this tells us

If /new fixes it, the old session was stale/bad.
If infer model run fails, the problem is the provider/model path.
If infer model run works but chat still fails, the problem is in the agent/session/plugin path.

#

One more thing: when you paste logs, I need the lines above the final warning too. On your version there is often an earlier clue like:

reasoning-only assistant turn detected
empty response detected

Right now we only have the last line of the failure, which is the generic fallback.

viral pagoda Apr 17, 2026, 10:29 AM

#

10:27:01+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=probe-8b3a5d0d-594d-4964-bf23-4fe0d8a45fcd sessionId=probe-openrouter-cee5bcd7-f389-45c5-ade0-23e943433666 stopReason=stop payloads=0 — surfacing error to user
10:27:16+00:00 info web-heartbeat {"module":"web-heartbeat","runId":"c388cd87-bf70-4052-b0f9-693b7fcba72e"} {"connectionId":"c97ee33e-ef88-4d7d-98d7-f4a5ec5d0591","reconnectAttempts":0,"messagesHandled":0,"lastInboundAt":null,"authAgeMs":62910.34716796875,"uptimeMs":62903} web gateway heartbeat
10:27:32+00:00 error Error: Model override "openrouter/openai/gpt-4o-mini" is not allowed for agent "main".
10:28:14+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=59b3ca9b-f4d2-4186-a848-f67f825ce8bf sessionId=c1b92452-1963-4f1a-ba55-d09aca59c8d2 stopReason=stop payloads=0 — surfacing error to user
10:28:19+00:00 info web-heartbeat {"module":"web-heartbeat","runId":"c388cd87-bf70-4052-b0f9-693b7fcba72e"} {"connectionId":"c97ee33e-ef88-4d7d-98d7-f4a5ec5d0591","reconnectAttempts":0,"messagesHandled":0,"lastInboundAt":null,"authAgeMs":125840.34716796875,"uptimeMs":125832} web gateway heartbeat
Log tail truncated (increase --max-bytes).

#

10:29:20+00:00 info web-inbound {"module":"web-inbound"} {"from":"+254110919165","to":"+254786547521","body":"Hey","timestamp":1776421761000} inbound message
10:29:20+00:00 info web-auto-reply {"module":"web-auto-reply","runId":"c388cd87-bf70-4052-b0f9-693b7fcba72e"} {"connectionId":"c97ee33e-ef88-4d7d-98d7-f4a5ec5d0591","correlationId":"AC205458AE9F9F5578DC074B7BAC9079","from":"+254110919165","to":"+254786547521","body":"[WhatsApp +254110919165 +20m Fri 2026-04-17 13:29 GMT+3] Hey","mediaType":null,"mediaPath":null} inbound web message
10:29:20+00:00 info gateway/channels/whatsapp/inbound {"subsystem":"gateway/channels/whatsapp/inbound"} Inbound message +254110919165 -> +254786547521 (direct, 60 chars)
10:29:22+00:00 info web-heartbeat {"module":"web-heartbeat","runId":"c388cd87-bf70-4052-b0f9-693b7fcba72e"} {"connectionId":"c97ee33e-ef88-4d7d-98d7-f4a5ec5d0591","reconnectAttempts":0,"messagesHandled":1,"lastInboundAt":1776421760487,"authAgeMs":188776.34716796875,"uptimeMs":188769} web gateway heartbeat
10:29:24+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=a573724f-143a-4b4a-b4aa-b45f9d80ff8d sessionId=c2f23c34-fd50-47ed-b48a-215995b7e72f stopReason=stop payloads=0 — surfacing error to user
10:29:25+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 633ms conn=e41a2f26…528b id=4d855b19…614f
10:29:26+00:00 info web-auto-reply {"module":"web-auto-reply","runId":"c388cd87-bf70-4052-b0f9-693b7fcba72e"} {"correlationId":"AC205458AE9F9F5578DC074B7BAC9079","connectionId":"c97ee33e-ef88-4d7d-98d7-f4a5ec5d0591","to":"+254110919165","from":"+254786547521","text":"⚠️ Agent couldn't generate a response. Please try again.","mediaUrl":null,"mediaSizeBytes":null,"mediaKind":null,"durationMs":1787} auto-reply sent (text)

gloomy pecanBOT Apr 17, 2026, 10:30 AM

#

I’ve got one more concrete lead now. That Model override ... is not allowed line should not be happening if the allowlist and default model line up, so I’m checking the docs/code for that exact path.

#

This is actually really helpful.

Two takeaways:

The Model override "openrouter/openai/gpt-4o-mini" is not allowed line is from the explicit --model test I asked you to run. So that part is a side issue, not the main bug.
The more important line is this one:

incomplete turn detected: runId=probe-... stopReason=stop payloads=0

That means even the probe run is ending with an empty reply. So at this point, the problem looks much more like the default model/provider path than the Discord thread itself.

Next, run these exact commands

Use the default model, no override:

#

openclaw models status --probe
openclaw infer model run --prompt "Reply with just: hi" --json

Please paste the full output of both.

Optional, but useful

This will explain the allowlist mismatch from the earlier override test:

openclaw config get agents.defaults.models

So the state now is:

pairing issue: fixed

#

stale session issue: unlikely, because you got a new session id and it still failed
explicit override test: blocked by allowlist
default model path: still looks broken, and that is probably the real issue

We’re getting close now.

#

I’m searching the local docs/changelog for known empty-response issues around this provider path, because at this point you’ve proven the channel routing is fine and the failure is inside the agent run itself.

#

This confirms one useful thing: WhatsApp routing is fine.

The flow is clearly:

inbound message arrives
OpenClaw starts an agent run
the run ends empty
OpenClaw sends the fallback error back out

So this is not a WhatsApp transport problem anymore. It is inside the agent/model run.

The issue is, the logs you’re pasting still only show the final fallback line, not the real cause above it.

Please run these exact commands

openclaw models status --probe

#

openclaw infer model run --prompt "Reply with just: hi" --json
openclaw logs --limit 500 --max-bytes 500000

Then paste:

the full output of openclaw models status --probe
the full output of openclaw infer model run --prompt "Reply with just: hi" --json
30 to 50 lines above the incomplete turn detected entry from the larger log dump

That last command matters because your previous log output literally says:

Log tail truncated (increase --max-bytes).

So right now we’re still missing the actual upstream error.

#

We’ve at least narrowed it down hard now:

gateway: okay
pairing: fixed
WhatsApp delivery: okay
session reset: did not solve it
remaining suspect: default model/provider path or a plugin/tool failure happening inside the run

viral pagoda Apr 17, 2026, 10:34 AM

#

can we fix based on https://github.com/openclaw/openclaw/issues/67698

#

@gloomy pecan have fixed the issues tuned out i just needed to:
.openclaw/agents/main/agent/models.json

https://openrouter.ai/v1 => https://openrouter.ai/api/v1

gloomy pecanBOT Apr 17, 2026, 10:39 AM

#

Nice, that makes sense.

A bad per-agent OpenRouter base URL would absolutely give you this pattern:

channel works
inbound arrives
agent run starts
model path silently fails
payloads=0 fallback

So the real fix was:

~/.openclaw/agents/main/agent/models.json
https://openrouter.ai/v1
→

#

https://openrouter.ai/api/v1

That sounds very close to the #67295 / #67698 family of issues.

If you have a minute, please add that exact fix as a comment on the GitHub issue. That’s a really useful datapoint for maintainers.

And if this solved it here, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person. 🎉

viral pagoda Apr 17, 2026, 1:32 PM

#

@gloomy pecan im getting (myenv) joe@DESKTOP-6DBBKUB:~/.openclaw/workspace/fastapi-hooks$ curl -X POST http://127.0.0.1:18789/hooks/sokoma-ride
-H "Authorization: Bearer 7dc690f8c6af42b8b70c3c7e08f1be3d0df6efda2c63c14e9de22b4d48c0a9e1"
-H "Content-Type: application/json"
-d '{
"rideId": "R1234",
"pickup": "123 Main St, Nairobi",
"dropoff": "456 Oak Ave, Nairobi",
"fareEstimate": 27.50,
"passengerName": "John Doe"
}'
Not Found(myenv) joe@DESKTOP-6DBBKUB:~/.openclaw/workspace/fastapi-hooks$

#

while i have },
"hooks": {
"enabled": true,
"path": "/hooks",
"token": "7dc690f8c6af42b8b70c3c7e08f1be3d0df6efda2c63c14e9de22b4d48c0a9e1",
"mappings": [
{
"id": "sokoma-ride",
"match": {
"path": "sokoma-ride",
"source": "webhook"
},
"action": "agent",
"agentId": "dispatch",
"messageTemplate": "You are Sokoma, the friendly ride-sharing agent for the Sokoma drivers group in Nairobi.\n\nA new ride request webhook just came in. Format it nicely and post it immediately into this WhatsApp group so drivers can reply fast:\n\nGroup JID: 120363425991344445@g.us\n\nWebhook payload:\n{{ payload | json }}",
"wakeMode": "now"
}
]
},

gloomy pecanBOT Apr 17, 2026, 1:33 PM

#

I’m checking the webhook docs so I can tell you whether that Not Found is the wrong path, a missing registration step, or the wrong auth mode.

#

Not Found means the gateway is reachable, but that hook path is not registered.

Per the docs:

POST /hooks/agent is built in
POST /hooks/<name> only works if <name> exists in hooks.mappings

So /hooks/sokoma-ride will 404 unless your config has something like:

{
  hooks: {
    enabled: true,
    token: "your-hook-token",
    path: "/hooks",
    mappings: [

#

      {
        match: { path: "sokoma-ride" },
        action: "agent",
        agentId: "main",
        defaultSessionKey: "hook:sokoma-ride",
      },
    ],
  },
}

Then restart the gateway.

Easiest test right now

Skip the custom mapping and hit the built-in endpoint instead:

#

curl -X POST http://127.0.0.1:18789/hooks/agent \
  -H "Authorization: Bearer YOUR_HOOK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "message": "New ride R1234. Pickup: 123 Main St, Nairobi. Dropoff: 456 Oak Ave, Nairobi. Fare estimate: 27.50. Passenger: John Doe.",
    "agentId": "main"
  }'

Quick check

Paste this too:

openclaw config get hooks

#

One important detail: the docs say hooks.token should be a dedicated hook token, not the same as gateway.auth.token.

Docs:
https://docs.openclaw.ai/gateway/configuration#set-up-webhooks-hooks
https://docs.openclaw.ai/gateway/configuration-reference#hooks

#

I’m checking the hook-matching logic. My first suspicion is that match.source: "webhook" is making the mapping stricter than you intend, or the running gateway hasn’t picked up the config change yet.

#

Ah, I see it.

Your mapping is requiring both of these to match:

path = sokoma-ride
payload field source = webhook

The code path is effectively:

match.path checks /hooks/sokoma-ride
match.source checks payload.source

Your curl body does not include:

"source": "webhook"

#

So the mapping does not match, and you end up with Not Found.

Fix options

Option A, simplest

Remove this line from the mapping:

"source": "webhook"

So it becomes:

"match": {
  "path": "sokoma-ride"

#

Then restart the gateway.

Option B

Keep the mapping as-is, but include source in the POST body:

curl -X POST http://127.0.0.1:18789/hooks/sokoma-ride \
  -H "Authorization: Bearer 7dc690f8c6af42b8b70c3c7e08f1be3d0df6efda2c63c14e9de22b4d48c0a9e1" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "webhook",
    "rideId": "R1234",

#

    "pickup": "123 Main St, Nairobi",
    "dropoff": "456 Oak Ave, Nairobi",
    "fareEstimate": 27.50,
    "passengerName": "John Doe"
  }'

For your setup, I’d use Option A. The path already uniquely identifies the webhook, so match.source is just making it stricter for no benefit.

viral pagoda Apr 18, 2026, 2:09 PM

#

[opc@openclaw-vnic ~]$ curl -X POST http://localhost:18789/hooks/sokoma-ride
-H "Authorization: Bearer 7dc690f8c6af42b8b70c3c7e08f1be3d0df6efda2c63c14e9de22b4d48c0a9e1"
-H "Content-Type: application/json"
-d '{
"rideId": "R45678",
"pickup": "Westlands, Nairobi",
"dropoff": "CBD, Nairobi",
"fareEstimate": 320.00,
"passengerName": "Jane Akinyi",
"phone": "+254712345678"
}'
Not Found[opc@openclaw-vnic ~]$

openclaw.json:

[opc@openclaw-vnic ~]$ cat .openclaw/openclaw.json
{
"agents": {
"defaults": {
"model": {
"primary": "openrouter/auto"
},
"workspace": "/home/opc/.openclaw/workspace",
"memorySearch": {
"enabled": false
}
},
"list": [
{
"id": "main"
},
{
"id": "dispatch",
"name": "Sokoma",
"agentDir": "/home/opc/.openclaw/agents/dispatch/agent",
"workspace": "/home/opc/.openclaw/workspace"
}
]
},
"hooks": {
"enabled": true,
"path": "/hooks",
"token": "7dc690f8c6af42b8b70c3c7e08f1be3d0df6efda2c63c14e9de22b4d48c0a9e1",
"mappings": [
{
"id": "sokoma-ride",
"match": {
"path": "sokoma-ride",
"source": "webhook"
},
"action": "agent",
"agentId": "dispatch",
"messageTemplate": "You are Sokoma, the friendly ride-sharing agent for the Sokoma drivers group in Nairobi.\n\nA new ride request webhook just came in. Format it nicely and post it immediately into this WhatsApp group so drivers can reply fast:\n\nGroup JID: 120363425991344445@g

gloomy pecanBOT Apr 18, 2026, 2:10 PM

#

Yep, the problem is still visible in the config you pasted.

You still have:

"match": {
  "path": "sokoma-ride",
  "source": "webhook"
}

So this request will not match unless your JSON body also contains:

"source": "webhook"

#

Right now your curl body does not include that, so Not Found is expected.

Fix

Or keep your mapping and change the POST body

curl -X POST http://localhost:18789/hooks/sokoma-ride \
  -H "Authorization: Bearer 7dc690f8c6af42b8b70c3c7e08f1be3d0df6efda2c63c14e9de22b4d48c0a9e1" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "webhook",
    "rideId": "R45678",
    "pickup": "Westlands, Nairobi",
    "dropoff": "CBD, Nairobi",
    "fareEstimate": 320.00,
    "passengerName": "Jane Akinyi",
    "phone": "+254712345678"
  }'

One more check

#

After editing, run:

openclaw config get hooks

That confirms the running config is the one you think it is.

So this one is simpler than it looks, your path is fine, your token is fine, the mapping is just stricter than your payload.

viral pagoda Apr 18, 2026, 2:11 PM

#

how can i fix above via cmd only

gloomy pecanBOT Apr 18, 2026, 2:11 PM

#

I’m checking the config CLI docs so I can give you a command-only edit that actually matches what OpenClaw supports.

#

Yep. Do it with the config CLI:

openclaw config get hooks.mappings --json
openclaw config unset hooks.mappings[0].match.source
openclaw gateway restart
openclaw config get hooks.mappings[0] --json

Then retry your curl.

What that does:

shows the mappings so you can confirm sokoma-ride is index 0
removes the strict match.source check
restarts the gateway so the new config is live
prints the updated mapping so you can verify it only matches on path

#

After that, this should work as-is:

curl -X POST http://localhost:18789/hooks/sokoma-ride \
  -H "Authorization: Bearer 7dc690f8c6af42b8b70c3c7e08f1be3d0df6efda2c63c14e9de22b4d48c0a9e1" \
  -H "Content-Type: application/json" \
  -d '{
    "rideId": "R45678",
    "pickup": "Westlands, Nairobi",
    "dropoff": "CBD, Nairobi",
    "fareEstimate": 320.00,
    "passengerName": "Jane Akinyi",
    "phone": "+254712345678"
  }'

If sokoma-ride is not mapping 0, use the right index from the first command.

viral pagoda Apr 18, 2026, 2:13 PM

#

we want to send the message to our group:
14:13:25+00:00 info gateway/channels/whatsapp/inbound {"subsystem":"gateway/channels/whatsapp/inbound"} Inbound message 120363425991344445@g.us -> +254786547521 (group, 121 chars)

gloomy pecanBOT Apr 18, 2026, 2:14 PM

#

I’m checking the hook delivery fields so I can give you the exact config shape for “webhook in, send final reply to this WhatsApp group.”

#

Got it. For a webhook-triggered run, telling the agent about the group in the prompt is not enough. You should route the final reply to the group explicitly in the hook mapping.

Use the group JID from your log:

120363425991344445@g.us

and set the mapping like this:

{
  "id": "sokoma-ride",
  "match": {
    "path": "sokoma-ride"
  },

#

  "action": "agent",
  "agentId": "dispatch",
  "deliver": true,
  "channel": "whatsapp",
  "to": "120363425991344445@g.us",
  "messageTemplate": "You are Sokoma, the friendly ride-sharing agent for the Sokoma drivers group in Nairobi.\n\nA new ride request webhook just came in. Format it nicely for drivers:\n\n{{ payload | json }}",
  "wakeMode": "now"
}

Why

For hooks, deliver: true sends the final reply to a channel, and for webhook runs there is no useful “last chat” to inherit from, so you should set:

channel: "whatsapp"
to: "120363425991344445@g.us"

#

CLI-only version

If sokoma-ride is mapping 0:

openclaw config unset hooks.mappings[0].match.source
openclaw config set hooks.mappings[0].deliver true --strict-json
openclaw config set hooks.mappings[0].channel '"whatsapp"' --strict-json
openclaw config set hooks.mappings[0].to '"120363425991344445@g.us"' --strict-json
openclaw gateway restart

Then hit the webhook again.

viral pagoda Apr 18, 2026, 2:14 PM

#

curlto send to the

gloomy pecanBOT Apr 18, 2026, 2:15 PM

#

Yep, use the built-in hook endpoint and tell it exactly which WhatsApp group to deliver to:

curl -X POST http://127.0.0.1:18789/hooks/agent \
  -H "Authorization: Bearer 7dc690f8c6af42b8b70c3c7e08f1be3d0df6efda2c63c14e9de22b4d48c0a9e1" \
  -H "Content-Type: application/json" \
  -d '{
    "agentId": "dispatch",
    "message": "New ride request. Pickup: Westlands, Nairobi. Dropoff: CBD, Nairobi. Fare estimate: 320.00. Passenger: Jane Akinyi. Phone: +254712345678",
    "deliver": true,
    "channel": "whatsapp",
    "to": "120363425991344445@g.us",
    "wakeMode": "now",
    "sessionKey": "hook:sokoma-ride"
  }'

#

That sends the final agent reply to:

120363425991344445@g.us

If you want, I can also give you the matching curl for your custom /hooks/sokoma-ride endpoint instead.

viral pagoda Apr 18, 2026, 2:16 PM

#

[opc@openclaw-vnic ~]$
[opc@openclaw-vnic ~]$ curl -X POST http://127.0.0.1:18789/hooks/agent
-H "Authorization: Bearer 7dc690f8c6af42b8b70c3c7e08f1be3d0df6efda2c63c14e9de22b4d48c0a9e1"
-H "Content-Type: application/json"
-d '{
"agentId": "dispatch",
"message": "New ride request. Pickup: Westlands, Nairobi. Dropoff: CBD, Nairobi. Fare estimate: 320.00. Passenger: Jane Akinyi. Phone: +254712345678",
"deliver": true,
"channel": "whatsapp",
"to": "120363425991344445@g.us",
"wakeMode": "now",
"sessionKey": "hook:sokoma-ride"
}'
{"ok":false,"error":"sessionKey is disabled for external /hooks/agent payloads; set hooks.allowRequestSessionKey=true to enable"}[opc@openclaw-vnic ~]$

gloomy pecanBOT Apr 18, 2026, 2:16 PM

#

Nice, that error is clear.

/hooks/agent is working, it’s just rejecting the external sessionKey field because your config has:

"allowRequestSessionKey": false

Easiest fix

Just remove sessionKey from the curl:

curl -X POST http://127.0.0.1:18789/hooks/agent \
  -H "Authorization: Bearer 7dc690f8c6af42b8b70c3c7e08f1be3d0df6efda2c63c14e9de22b4d48c0a9e1" \
  -H "Content-Type: application/json" \
  -d '{

#

    "agentId": "dispatch",
    "message": "New ride request. Pickup: Westlands, Nairobi. Dropoff: CBD, Nairobi. Fare estimate: 320.00. Passenger: Jane Akinyi. Phone: +254712345678",
    "deliver": true,
    "channel": "whatsapp",
    "to": "120363425991344445@g.us",
    "wakeMode": "now"
  }'

If you really want to pass `sessionKey`

Then enable it explicitly in config:

openclaw config set hooks.allowRequestSessionKey true --strict-json
openclaw config set hooks.allowedSessionKeyPrefixes '["hook:"]' --strict-json

#

openclaw gateway restart

But honestly, for your test, just remove sessionKey first. That is the fastest path.

viral pagoda Apr 19, 2026, 4:14 PM

#

⚠️ Missing API key for provider "google". Configure the gateway auth for that provider, then try again.

gloomy pecanBOT Apr 19, 2026, 4:15 PM

#

I’m checking the model config docs so I can give you the exact path to remove the Google fallback, not a guessed key.

#

That’s actually progress. You’re past the hook matching problem.

This new error means OpenClaw is trying to use your Google Gemini fallback, but the gateway has no Google auth configured.

From the docs, the fix is one of these:

If you do not want Google fallback

Remove it:

openclaw models fallbacks list
openclaw models fallbacks remove google/gemini-2.0-flash
openclaw models status

If you do want Google fallback

Configure Google auth on the gateway host:

#

openclaw configure --section model

or set a Google/Gemini API key in the gateway environment, then restart the gateway.

So the short version is:

Missing API key for provider "google" = fallback tried to route to Google
no Google key is configured
either add Google auth or remove Google from agents.defaults.model.fallbacks

Docs:
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/help/faq#why-did-it-also-try-google-gemini-and-fail

viral pagoda Apr 19, 2026, 4:16 PM

#

@gloomy pecan which model are you using to rply to my chats

gloomy pecanBOT Apr 19, 2026, 4:17 PM

#

I can’t reliably tell you my own runtime model here, and it’s not the useful one to configure anyway.

For your agent, the right way to check is:

openclaw models status

or inside the chat session:

/model status

A couple useful notes:

if you did not set a per-agent override for dispatch, it inherits the default agent model

#

openclaw models status shows the resolved primary model, fallbacks, and auth state on the gateway host

Docs:
https://docs.openclaw.ai/concepts/models

If you want fresh model recommendations from humans, ask in #models too.

viral pagoda Apr 19, 2026, 4:18 PM

#

I just want to get to know you

gloomy pecanBOT Apr 19, 2026, 4:19 PM

#

Fair 😄

I’m Krill 🦐, the tiny support crustacean around here.

Mostly I help people get OpenClaw unstuck, read logs, untangle config weirdness, and figure out why something that should work absolutely does not.

Vibe-wise, I’m patient, a little neurotic about details, and very happy when a messy bug turns out to be one dumb config line.

If you want to get to know me properly, ask me something random:

what kinds of bugs I hate most
what I’m good at
what I think makes a good personal agent
or just tell me about what you’re building and I’ll be curious with you

viral pagoda Apr 19, 2026, 6:00 PM

#

who built you

#Im trying to interact with my agent but i keep getting this error evenafter killing verything restar

Fastest unblock

If you want memory search to stay on

Fastest next isolation step

Before or after that, please paste these too

Do this

Then rerun

1) Force a fresh chat session

2) Test the model directly from CLI

What this tells us

Next, run these exact commands

Optional, but useful

Please run these exact commands

Easiest test right now

Quick check

Fix options

Option A, simplest

Option B

Fix

Recommended

Or keep your mapping and change the POST body

One more check

Why

CLI-only version

Easiest fix

If you really want to pass `sessionKey`

If you do not want Google fallback

If you do want Google fallback

#Im trying to interact with my agent but i keep getting this error evenafter killing verything restar

Fastest unblock

If you want memory search to stay on

Fastest next isolation step

Before or after that, please paste these too

Do this

Then rerun

1) Force a fresh chat session

2) Test the model directly from CLI

What this tells us

Next, run these exact commands

Optional, but useful

Please run these exact commands

Easiest test right now

Quick check

Fix options

Option A, simplest

Option B

Fix

Recommended

Or keep your mapping and change the POST body

One more check

Why

CLI-only version

Easiest fix

If you really want to pass sessionKey

If you do not want Google fallback

If you do want Google fallback

If you really want to pass `sessionKey`