#Hooks

1 messages · Page 1 of 1 (latest)

fair lily
#

What is the hoosk setup

nova rivetBOT
viscid patioBOT
#

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

nova rivetBOT
rain lanternBOT
#

Assuming you meant hooks in OpenClaw, there are really 2 setups:

  1. Internal hooks
    Small scripts that run on Gateway events like /new, /reset, startup, message received, etc.

    Quick flow:

    • put hook dirs in <workspace>/hooks/ or ~/.openclaw/hooks/
    • inspect with openclaw hooks list
    • enable with openclaw hooks enable <name>
    • restart the gateway

  2. Webhooks
    HTTP endpoints for external systems to trigger OpenClaw.

    Minimal config:

# 
   {
     hooks: {
       enabled: true,
       token: "long-random-secret",
       path: "/hooks",
       defaultSessionKey: "hook:ingress",
       allowRequestSessionKey: false,
       allowedSessionKeyPrefixes: ["hook:"],
       allowedAgentIds: ["hooks", "main"],
     },
   }

Endpoints:

  • POST /hooks/wake
  • POST /hooks/agent
#
  • Gmail webhook flow
fair lily
#

What are hooks

rain lanternBOT
#

Hooks are basically event-driven automations in OpenClaw.

Think of them as: “when X happens, run Y.”

Two kinds:

  • Internal hooks: small scripts that run inside the Gateway on events like:

    • /new
    • /reset
    • gateway startup
    • message received/sent
    • agent bootstrap

  • Webhooks: HTTP endpoints other apps can call to trigger OpenClaw from outside

Examples:

  • save session memory when /new runs
fair lily
#

Gateway not working logs says need pairing

rain lanternBOT
#

If the logs say PAIRING_REQUIRED or disconnected (1008): pairing required, the thing connecting to the Gateway has not been approved yet.

First, please paste:

openclaw --version

Then try this:

openclaw gateway status
openclaw devices list

If you see a pending request, approve it:

# 
openclaw devices approve <requestId>

That’s the usual fix for:

  • Control UI / dashboard first connection
  • browser/device auth
  • node/device pairing

If this is chat/DM pairing instead of a browser/device, use:

openclaw pairing list --channel <channel>
openclaw pairing approve <channel> <code>

If you want the shortest debug path, paste the output of:

fair lily
#

All devices approved but still nothing

rain lanternBOT
#

If all devices are already approved, then this usually is not pairing anymore. It’s usually one of these:

  1. stale token / token drift
  2. a new pending request replaced the old one
  3. wrong gateway URL / wrong auth field
  4. remote/Tailscale browser path instead of local loopback

Try this exact sequence:

openclaw --version
openclaw status
openclaw gateway status
openclaw devices list
openclaw config get gateway.auth.token
openclaw doctor
#

A few important checks:

  • Re-run openclaw devices list right now. If the browser retried with changed auth details, the old request can be superseded by a new requestId.
  • If you’re local, open http://127.0.0.1:18789/. Local loopback should auto-approve.
  • In Control UI, paste the current token from:
    openclaw config get gateway.auth.token

If it still fails, do token-drift repair on the affected device:

openclaw devices list
openclaw devices rotate --device <deviceId> --role operator

If that still doesn’t fix it:

fair lily
#

Just unnitall and setip again?

rain lanternBOT
#

I wouldn’t jump to uninstall yet.

For pairing/auth issues, reinstall often doesn’t help, because the problem is usually in the device/token state, not the app binary.

I’d do this first:

openclaw --version
openclaw doctor
openclaw devices list

Then repair the affected device instead of reinstalling:

openclaw devices rotate --device <deviceId> --role operator
#

If that fails:

openclaw devices remove <deviceId>
openclaw devices list
openclaw devices approve <requestId>

Then reconnect and make sure you’re using the current token:

openclaw config get gateway.auth.token

Only if that all fails, then I’d do a clean setup again.

If you want, paste:

#
  • openclaw --version
  • openclaw doctor
  • openclaw devices list

and I’ll tell you whether it’s worth reinstalling or not.

fair lily
#

Devices list everyhting is paird

rain lanternBOT
#

Okay, that’s useful, it means plain pairing is probably not the issue.

At this point the most likely causes are:

  • token drift
  • wrong gateway URL
  • wrong auth token/password in Control UI
  • a stale browser device token

Next commands I’d run:

openclaw --version
openclaw status
openclaw gateway status
openclaw doctor
# 
openclaw config get gateway.auth.token

If this is the dashboard / Control UI:

  • use http://127.0.0.1:18789/ if you’re on the same machine
  • paste the token from:
    openclaw config get gateway.auth.token

If it still fails after that, repair the specific browser/device token:

openclaw devices rotate --device <deviceId> --role operator
#

and if needed:

openclaw devices remove <deviceId>

then reconnect so it creates a fresh pairing request.

If you paste these two outputs, I can probably tell which bucket it is right away:

openclaw gateway status
openclaw doctor
fair lily
#

Ok i reinstalled but now says onboaridn complete and on dashboard when enter hi nothing comes just says assistant

rain lanternBOT
#

That’s progress, honestly. If the dashboard opens and creates an “assistant” message bubble, the UI is talking to the Gateway now, but the agent/model run isn’t finishing.

I would check this next, in order:

openclaw --version
openclaw gateway restart
openclaw status
openclaw models status
openclaw logs --follow
openclaw doctor

What I’m looking for:

  • openclaw status → gateway reachable
  • openclaw models status → a model is actually configured/authenticated
fair lily
#

Open claw status -> gateway reachable
Openclaw model stattus i can see rhe model

rain lanternBOT
#

Nice, that rules out the obvious stuff. If gateway is reachable and the model shows up, the next step is to catch the actual run error.

Please run:

openclaw --version
openclaw models status --probe
openclaw logs --follow

Then, while logs --follow is open, send hi again in the dashboard and paste the new log lines here.

That should tell us whether it’s:

  • provider auth failing at runtime
  • model blocked / cooling down
  • agent bootstrapping crash
  • some other run-time error
#

If you can, also paste:

openclaw status --all

That’ll make this a lot faster to pin down.

#

Nice, this is actually really helpful.

Your model auth probe is OK, so this is not an OpenRouter/API-key problem.

That means the failure is more likely in:

  • agent startup / bootstrapping
  • session state
  • runtime error after chat.send starts

Please paste these next:

openclaw --version
openclaw status --all
openclaw doctor
#

And the most important one:

openclaw logs --follow

Then send hi again in the dashboard and paste the new log lines right after that.

At this point I’m specifically looking for words like:

  • bootstrapping
  • session
  • trim
  • error
  • failed
  • timeout

We’re pretty close now, because we’ve already ruled out pairing and model auth.

#

Yep, we found it.

This is not a reinstall issue and not a model issue.
It’s a device scope upgrade problem.

Your logs say the device is paired, but only with:

  • current scopes: operator.read

and now it wants:

  • operator.admin
  • operator.approvals
  • operator.pairing
  • operator.write
  • operator.talk.secrets
#

That’s why it keeps failing with pairing required even though the device already exists.

Fix

First check pending requests:

openclaw devices list

Then approve the pending scope-upgrade request. If that request id is still there, use:

openclaw devices approve 30ff843b-9da5-43d7-9194-d2b15dc9bf8e

If devices list shows a newer request id, approve that one instead.

#

Perfect, that’s the right approval.

The important line is:

Approved 9d89efbf... (30ff843b-...)

So the scope upgrade went through. Now:

  1. refresh/reopen the dashboard
  2. send hi again

If it still fails once more, do:

# 
openclaw gateway restart

then reopen the dashboard and retry.

That Direct scope access failed; using local fallback. line is okay here, the approval still succeeded.

If hi works now, you should be good 🎉
If not, paste the next log lines after retrying and I’ll keep going.

#

We’re very close, but that line is still just the symptom, not the cause.

This means:

  • the turn started
  • then it stopped with no output
  • so OpenClaw surfaced an incomplete turn error

The real error should be a few lines above that, but your log output got truncated.

Please rerun with a bigger log buffer:

openclaw logs --follow --max-bytes 200000

Then send hi again and paste the 10 to 20 lines before this warning.

#

If openclaw logs still truncates, use the raw log file instead:

tail -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

What I need is the line(s) right before:

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

That should expose the actual failure. Right now we’ve proven:

  • pairing is fixed
  • gateway is reachable
  • model auth is okay
#

So the remaining issue is almost certainly the runtime/provider response for that turn.

#

This is enough to narrow it down.

Your dashboard connection is fine and pairing is fixed.
What’s failing now is the actual model turn. The key clue is that even the tiny slug-generator run is dying with:

  • stopReason=stop
  • payloads=0

So the current route is starting, then returning no text at all.

Fastest isolate

Run this:

openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json
#

If that also fails or comes back empty, I’d switch off the current default temporarily and retry:

openclaw models set openrouter/auto
openclaw gateway restart

Then reopen the dashboard and send hi again.

Why I’m suggesting that

This no longer looks like:

  • pairing
  • dashboard
  • gateway reachability
  • missing auth
#

It looks like the current model route is returning an empty turn.

If you paste the result of:

openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json

I can tell you pretty quickly if that’s the culprit.

#

Yep, that confirms it.

The problem is the current default model route.
It’s failing even on a tiny direct smoke test, so this is not the dashboard, hooks, pairing, or general gateway setup anymore.

Quick fix

Switch away from that default for now:

openclaw models set openrouter/auto
openclaw gateway restart

Then retry:

# 
openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json

If that works, reopen the dashboard and send hi.

What we learned

Your current route:

  • provider: openrouter
  • model: minimax/minimax-m2.5

is returning empty turns (stopReason=stop, payloads=0), which is why OpenClaw keeps saying:

Agent couldn't generate a response.

#

So right now I’d treat this as a bad model route / provider response issue, not a local install issue.

If openrouter/auto works, you’re unblocked.
If it still fails, paste the new infer model run output and I’ll keep digging.

If this fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

fair lily
#

so the model is not working?

rain lanternBOT
#

Yes, but more specifically:

  • auth is working
  • OpenClaw can see the model
  • but this specific model route is not returning usable output

So it’s not “your whole setup is broken”, it’s more like:

the current default model is connecting, then returning an empty turn

That’s why I suggested switching to:

openclaw models set openrouter/auto
openclaw gateway restart
#

So, short answer: yes, this model route is not working properly right now.
Not your install, not pairing, not the dashboard.

If you want, after you switch, paste the new smoke test result and I’ll confirm you’re clear.

#

Yeah, at this point I’d say your current OpenRouter-backed model path is not working for agent runs.

You’ve already ruled out:

  • pairing
  • dashboard
  • gateway reachability
  • basic auth
  • the specific minimax route
  • even openrouter/auto

So the issue is now probably one of these:

  1. OpenRouter route/provider behavior in full agent runs
  2. tool-schema compatibility with the selected route
  3. a lower-level OpenClaw bug on this setup
#

Best next move, recommended

Fastest unblock: configure a different provider/model path and retry.

If you want fresh “what model actually works well right now” advice, ask in #models. That changes fast, and I don’t want to send you to a dead route.

Docs:

If you want to keep debugging this exact path

I can walk you through the more advanced route next, which is testing whether the current route is choking on OpenClaw’s tool schema surface.

My recommendation: don’t keep fighting this route right now. Switch provider/model first, get the app working, then come back to this if you want.

fair lily
#

what openrouter is working fine for everyone

rain lanternBOT
#

I wouldn’t trust a hardcoded answer from me on that, because OpenRouter recommendations change fast and stale advice is how people get sent into a wall.

Best move:

What I can say confidently is:

  • your setup is past pairing/auth issues
  • your current OpenRouter path is returning empty turns
  • so you should switch to a currently-known-good route from #models, rather than keep guessing here

If you get a model recommendation from #models and want me to sanity-check the setup steps, I can do that.

fair lily
#

use gemma model from open router

rain lanternBOT
#

Yep, you can try that, just use the exact OpenRouter Gemma ref from your catalog instead of guessing it.

Run:

openclaw models list --provider openrouter | grep -i gemma

Then set the exact one it shows:

openclaw models set openrouter/<provider>/<exact-gemma-model-id>
openclaw gateway restart
openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json

I don’t want to invent the exact model string, because OpenRouter’s catalog changes.

#

If you paste the models list line(s) for Gemma, I’ll tell you the exact models set ... command to run.

fair lily
#

help me fix

rain lanternBOT
#

Do this:

openclaw models list --provider openrouter | grep -i gemma

Then copy one of the exact model refs it shows and run:

openclaw models set openrouter/<provider>/<exact-gemma-model-id>
openclaw gateway restart
openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json

If that returns smoke-ok, reopen the dashboard and try hi.

If you want, paste the output of:

# 
openclaw models list --provider openrouter | grep -i gemma

and I’ll give you the exact openclaw models set ... command.

fair lily
#

openclaw models list --provider openrouter | grep -i gemma

whne i use this it just doenst return anything

rain lanternBOT
#

Got it, that means your current OpenRouter catalog isn’t showing any Gemma refs, so don’t burn time on that path right now.

Do this instead:

openclaw models list --provider openrouter

Two options from there:

  1. Fastest unblock: pick any concrete OpenRouter model from that list, then run:
    openclaw models set <exact-model-ref>
openclaw gateway restart
openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json
#
  1. Best real-time advice: ask in #models which exact OpenRouter ref people are successfully using right now, then set that exact ref.

I don’t want to guess a model name here and send you into another dead end.

If you paste the output of:

openclaw models list --provider openrouter

I can help you format the exact openclaw models set ... command.

fair lily
#

chotumiya@chotus-Mac-mini ~ % openclaw models list --provider openrouter

🦞 OpenClaw 2026.4.15 (041266a) — Your config is valid, your assumptions are not.

Model Input Ctx Local Auth Tags
openrouter/auto text+image 1953k no yes default,configured,alias:OpenRouter
openrouter/minimax/minimax-m2.5 text 192k no yes configured
returns only eh one using not all list

rain lanternBOT
#

Yep, that’s expected.

openclaw models list is showing your configured/resolved models, not the full OpenRouter catalog.

For discovery, use:

openclaw models scan

If you want OpenClaw to pick a scanned candidate and set it as default:

openclaw models scan --set-default

Then:

# 
openclaw gateway restart
openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json

If you only want to inspect candidates first without live probing, use:

openclaw models scan --no-probe

So the fix path here is:

  1. scan
  2. set a new default
  3. restart
  4. rerun the smoke test
#

I’m worried this is a real bug or bad local runtime state, not just “pick a different OpenRouter model.”

Why I think that:

  • pairing is fixed
  • gateway is reachable
  • auth probe is okay
  • infer model run fails
  • changing from minimax to openrouter/auto didn’t help
  • the failure is the same every time: stopReason=stop payloads=0

So I would stop burning time swapping models at this point.

My recommendation

Please file a GitHub issue with these exact bits:

#
  • openclaw --version → 2026.4.15 (041266a)
  • openclaw models status --probe
  • openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json
  • the pairing required / scope-upgrade log
  • the repeated incomplete turn detected ... payloads=0 logs

Issue link:
https://github.com/openclaw/openclaw/issues

Short summary to paste into the issue

OpenClaw 2026.4.15 on macOS, gateway reachable, OpenRouter auth probe OK, but all agent runs fail with incomplete turn detected ... stopReason=stop payloads=0.
Reproduces in dashboard and with openclaw infer model run.
Reproduces after switching from openrouter/minimax/minimax-m2.5 to openrouter/auto.
Pairing scope-upgrade was approved successfully, but model runs still return ⚠️ Agent couldn't generate a response.

If you want, I can help you turn everything you already pasted into a clean issue report message.

fair lily
#

yes

rain lanternBOT
#

Paste this into a GitHub issue:

Title
2026.4.15: agent runs stop with payloads=0 on OpenRouter routes even though auth probe is OK

Body

## Summary

OpenClaw is installed and the gateway is reachable, but all agent runs fail with:

- `incomplete turn detected`
- `stopReason=stop`
- `payloads=0`

This reproduces both in the dashboard and with `openclaw infer model run`.
# 

## Version

```bash
openclaw --version

Output:

OpenClaw 2026.4.15 (041266a)

Environment

# 
- macOS
- OpenClaw installed via Homebrew global path
- OpenRouter API key configured in auth profiles

## What I expected

A normal text reply in the dashboard and from `openclaw infer model run`.

## What happened instead

The dashboard creates an assistant bubble but no actual response appears.

Direct infer also fails:

```bash
openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json
# 

Output:

```text
15:11:19 [agent/embedded] incomplete turn detected: runId=6ab6183b-7f5c-462d-8918-65fe87ee9e5b sessionId=6ab6183b-7f5c-462d-8918-65fe87ee9e5b stopReason=stop payloads=0 — surfacing error to user
{
  "ok": true,
  "capability": "model.run",
  "transport": "local",
  "provider": "openrouter",
  "model": "minimax/minimax-m2.5",
  "attempts": [],
  "outputs": [
    {
      "text": "⚠️ Agent couldn't generate a response. Please try again.",
      "mediaUrl": null
#

}
]
}


After switching the default model to `openrouter/auto`, the same failure still happens:

```bash
openclaw models set openrouter/auto
openclaw gateway restart
openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json

Output:

15:14:42 [agent/embedded] incomplete turn detected: runId=6ab6183b-7f5c-462d-8918-65fe87ee9e5b sessionId=6ab6183b-7f5c-462d-8918-65fe87ee9e5b stopReason=stop payloads=0 — surfacing error to user
#

{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "openrouter",
"model": "openrouter/auto",
"attempts": [],
"outputs": [
{
"text": "⚠️ Agent couldn't generate a response. Please try again.",
"mediaUrl": null
}
]
}

# 
## Auth status

`openclaw models status --probe` shows OpenRouter auth is OK.

Relevant output:

```text
Default : openrouter/minimax/minimax-m2.5
Configured models (2): openrouter/auto, openrouter/minimax/minimax-m2.5

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

Auth probes
openrouter/minimax/minimax-m2.5 -> ok
# 

## Model list

```bash
openclaw models list --provider openrouter

Output:

openrouter/auto
openrouter/minimax/minimax-m2.5

Relevant logs

# 

Before fixing pairing, I hit a scope-upgrade pairing issue:

```text
security audit: device access upgrade requested reason=scope-upgrade
roleFrom=node,operator
scopesFrom=operator.read
scopesTo=operator.admin,operator.approvals,operator.pairing,operator.read,operator.talk.secrets,operator.write
gateway connect failed: GatewayClientRequestError: pairing required

I approved the pending request successfully:

Approved 9d89efbf5bcbd5e785ef49e73e8d6d9e8c2c2b161bf007c7c4369a895a86b9c1 (30ff843b-9da5-43d7-9194-d2b15dc9bf8e)
# 

After that, pairing was fixed, but agent runs still failed with repeated incomplete-turn logs:

```text
warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=a8c40ca4-8bb4-48ac-9a71-eb5aa57335ce sessionId=2833a4a6-c3d1-4358-8f65-56abf1af865d stopReason=stop payloads=0 — surfacing error to user
warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=904dac04-ba1e-41ea-8c69-a3ca7804ee4f sessionId=2833a4a6-c3d1-4358-8f65-56abf1af865d stopReason=stop payloads=0 — surfacing error to user
warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=slug-gen-1776539043914 sessionId=slug-generator-1776539043914 stopReason=stop payloads=0 — surfacing error to user
info hooks/session-memory {"subsystem":"hooks/session-memory"} Session context saved to ~/.openclaw/workspace/memory/2026-04-18-agent-couldn-t-generate-a-resp.md

Repro steps

  1. Configure OpenRouter API key
  2. Set default model to openrouter/minimax/minimax-m2.5
  3. Open dashboard and send hi
# 
4. No usable response appears
5. Run:
   ```bash
   openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json
  1. Same incomplete-turn failure
  2. Switch default to openrouter/auto
  3. Retry
  4. Same failure

Notes

This does not look like:

  • gateway reachability
  • pairing (after approval)
# 
- missing auth
- just one bad model route

Because both a concrete OpenRouter route and `openrouter/auto` fail in the same way.

Issue link: https://github.com/openclaw/openclaw/issues

If they reply on the issue and you want help interpreting it, paste it here and I’ll help.

fair lily
#

can you try to fix

rain lanternBOT
#

I can help guide the fix, but I can’t directly change your Mac from here.

And honestly, at this point I think this needs either:

  1. a local agent that can inspect your machine and logs directly, or
  2. a GitHub issue for maintainer eyes

Fastest path:
https://docs.openclaw.ai/help/faq#i-am-stuck-fastest-way-to-get-unstuck

That’s the “use a local AI agent that can see your machine” route, which is way better for bugs like this than back-and-forth in Discord.

If you want to keep going here, I can still help you with safe read-only diagnostics, but I don’t want to pretend I can remotely patch your install from this thread.

fair lily
#

use a local AI agent that can see your machine”

rain lanternBOT
#

Yep, exactly, I mean something like Claude Code or OpenAI Codex running on your Mac, so it can inspect your actual files, config, and logs.

Good starting flow:

  1. install OpenClaw from a git checkout so the local agent can read the code/docs

    curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method git

  2. open a local coding agent and point it at the checkout

  3. ask it something like:

    OpenClaw 2026.4.15 is failing with incomplete turn detected ... payloads=0.
    Gateway reachable, OpenRouter auth probe OK, but dashboard and openclaw infer model run both fail.
    Please inspect my config, logs, and workspace, then propose the smallest fix.

  4. give it these commands/output too:

fair lily
#

what?

rain lanternBOT
#

I mean:

not me in Discord, but an AI coding tool running on your own Mac.

Like:

  • Claude Code
  • OpenAI Codex

Why:

  • it can open your files
  • read your actual logs/config
  • run commands locally
  • debug faster than doing this one message at a time

So basically:

install a coding agent on your Mac, point it at your OpenClaw setup, and let it inspect the machine directly

#

That’s what “local AI agent that can see your machine” means.

fair lily
#

claude code fixed it

rain lanternBOT
#

Nice, glad you got it unstuck 🎉

If you know what Claude Code changed, please post the fix here too, that’d really help the next person.

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

fair lily
#

not sure

rain lanternBOT
#

No worries, the important part is it’s working now 🙂

If you figure out later what changed, drop it in the thread. And if this solved it, please right-click the solution message → Apps → ✅ Mark Solution so it gets indexed for future folks.