Cant Trigger Hook

[sturdy venture]

def trigger_openclaw(subject: str, sender: str, body: str):
snippet = body[:500] + ("…" if len(body) > 500 else "")
payload = {
"message": f"""WEBHOOK TRIGGER — EMAIL RECEIVED
NON-INTERACTIVE. NO HUMAN PRESENT. DO NOT OUTPUT TO CHAT.

---

FROM: {sender}
SUBJECT: {subject}
BODY:
{snippet}

PROTOCOL:

1. Read MEMORY.md.
2. Check sender trust (trusted: @XXXXX.dev, XXXXX).
   • UNTRUSTED: Reply via email to {sender} — tell them they are not a trusted sender and to contact spXXX.dev instead. Then stop.
   • TRUSTED: Continue.
3. Execute the requested action. Use tools. Do not ask questions.
4. Reply to sender via email (msmtp). Escalate blockers to Paul via Telegram only.
5. Append one-sentence summary + sender to EMAILS.md.
6. Delete temp files.""",
   "name": "Email",
   "wakeMode": "now",
   "deliver": True,
   "channel": "telegram",
   "model": "openrouter/minimax/minimax-m2",
   "sessionKey": "hook📧ingress",
   }
   resp = requests.post(
   OPENCLAW_HOOK_URL,
   json=payload,
   headers={"Authorization": f"Bearer {OPENCLAW_HOOK_TOKEN}"},
   timeout=10,
   )
   resp.raise_for_status()

I cant send hooks
i get:
401 Client Error: Unauthorized for url: http://127.0.0.1:18791/hooks/agent

This is my config

"hooks": {
"enabled": true,
"token": "YOUR_HOOK_TOKEN_HERE",
"path": "/hooks",
"defaultSessionKey": "hook:ingress",
"allowedAgentIds": ["hooks", "main"]
},

@wanton marten

[wanton marten]

That config snippet explains the 401.

You currently have:

"token": "YOUR_HOOK_TOKEN_HERE"

If that is literally in openclaw.json, then your request must send that exact string as bearer token — otherwise auth fails with 401.

Fix checklist

1. Set a real hook token (not placeholder), e.g. a long random value.
2. Send that exact same value in:

• Authorization: Bearer <hooks.token>

3. Restart gateway after config changes:

• openclaw gateway restart

4. Verify where gateway is actually listening:

• openclaw gateway status
  (you’re posting to 127.0.0.1:18791; default is 18789 unless you changed gateway.port)

One more thing in your payload

You send:

"sessionKey": "hook📧ingress"

With your config, request sessionKey overrides are disabled by default, so that will fail (usually 400, not 401).
Either remove sessionKey from payload, or explicitly enable:

hooks: {

allowRequestSessionKey: true,
allowedSessionKeyPrefixes: ["hook:"]
}

Also please paste:

openclaw --version

and I can sanity-check version-specific behavior quickly.

Docs: https://docs.openclaw.ai/automation/webhook

[sturdy venture]

root@openclaw:~# openclaw --version
OpenClaw 2026.3.22 (4dcc39c)
root@openclaw:~#

I removed the session key thing from the py script and changed the tokens for a propper one. still 401..

Ye i still get this bs
2026-03-23 17:36:14 [ERROR] Luna trigger failed for 'Yo': 401 Client Error: Unauthorized for url: http://127.0.0.1:18791/hooks/agent

Btw its the correct port

[wanton marten]

Yeah — if it’s still 401, that means the request is reaching /hooks/agent, but the token check is failing.
So this is almost certainly a token mismatch (not payload shape).

Do this exact 3‑minute check:

1. Check which config the running service is using

openclaw gateway status

Look at Config (service) vs Config (cli) — if they differ, you edited the wrong file/profile.

2. Test hook auth directly with curl

curl -i -X POST http://127.0.0.1:18791/hooks/agent \
-H "x-openclaw-token: YOUR_REAL_HOOK_TOKEN" \
-H "Content-Type: application/json" \

-d '{"message":"ping"}'

• If this returns 401: token in running gateway is different.
• If this returns 200: your Python env/header value is wrong.

3. Check Python token exactly
   Log:

• repr(OPENCLAW_HOOK_TOKEN)
• len(OPENCLAW_HOOK_TOKEN)

Common gotchas:

• trailing newline/space
• quotes included in env value ("token" instead of token)
• storing Bearer ... in env (don’t; env should be raw token only)

Also: once auth works, your current payload includes sessionKey, and with your config that will then fail with 400 unless you enable hooks.allowRequestSessionKey=true.

So either remove sessionKey now or enable it.

If you paste openclaw gateway status output, I can pinpoint it fast.

Perfect — if port is correct, then we can narrow this hard:

401 on /hooks/agent = hook token mismatch.
(That route returns 401 only when safeEqual(token, hooks.token) fails.)

So next move is to compare token values exactly, not eyeballing:

# terminal where python runs
python - <<'PY'
import os, hashlib
t=os.getenv("OPENCLAW_HOOK_TOKEN","")
print("py len:", len(t), "sha256:", hashlib.sha256(t.encode()).hexdigest())
PY

Then on gateway host config token (same actual profile the service uses), print the same hash.

If hashes differ, that’s your 401.

Also make sure your env token is raw token only (no Bearer prefix, no quotes, no newline).

And yeah — once auth is fixed, remove sessionKey from payload (or enable hooks.allowRequestSessionKey) or you’ll hit a 400 next.

[sturdy venture]

root@openclaw:~# openclaw gateway status

🦞 OpenClaw 2026.3.22 (4dcc39c) — Half butler, half debugger, full crustacean.

│
◇
Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-03-23.log

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH is not set; the daemon should use a minimal PATH.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (env/config)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: stopped (state inactive, sub dead, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
root@openclaw:~#

18791 is an api that returns 401
and the standard 18789 returns 404

i run openclaw with a custom systemctl service btw

curl did
-H "Content-Type: application/json" \

HTTP/1.1 401 Unauthorized
X-Powered-By: Express
Content-Type: text/html; charset=utf-8
Content-Length: 12
ETag: W/"c-dAuDFQrdjS3hezqxDTNgW7AOlYk"
Date: Mon, 23 Mar 2026 16:41:33 GMT
Connection: keep-alive
Keep-Alive: timeout=5

Unauthorizedroot@openclaw:~#

Tokens match

[wanton marten]

Nice, this output is super clear now.

X-Powered-By: Express on 18791 means that endpoint is not OpenClaw gateway hooks.
So your Python is hitting a different API entirely.

And on 18789:

• OpenClaw is there (RPC probe: ok)
• /hooks/agent returning 404 means hooks route is not active on that running instance (hooks disabled or different config/path)

What to do

1. Point your webhook URL to the actual gateway:

• http://127.0.0.1:18789/hooks/agent

2. Ensure the running OpenClaw process has hooks enabled in its loaded config:

hooks: { enabled: true, token: "...", path: "/hooks" }

3. Restart the process you actually run (your custom systemd unit).

4. Re-test:

curl -i -X POST http://127.0.0.1:18789/hooks/agent \
-H "x-openclaw-token: <hooks.token>" \
-H "Content-Type: application/json" \
-d '{"message":"ping"}'

Expected: 200 (accepted) or 400 (payload issue), but not 404/401 if URL+token are correct.

---

Given you use a custom unit, check what it really starts:

systemctl cat <your-unit>
systemctl show <your-unit> -p ExecStart -p Environment

I’m pretty confident the fix is: wrong service/port target + hooks not active on the real gateway process.

[sturdy venture]

Okay weird because in the config that always changed and then actually i sawthe change happen now has hooks.enabled: true but the control ui shows disabled

[wanton marten]

Yep, that’s classic split-brain: UI and file are looking at different runtime/process state.

If config says hooks.enabled: true but UI says disabled, one of these is true:

1. UI is connected to a different gateway URL/port
2. Another process is serving that port
3. Running gateway failed to reload config (kept old state)

Quick read-only checks:

openclaw gateway status
ss -ltnp | egrep '18789|18791'
curl -i -X POST http://127.0.0.1:18789/hooks/agent -H "x-openclaw-token: <token>" -H "Content-Type: application/json" -d '{"message":"ping"}'
curl -i -X POST http://127.0.0.1:18791/hooks/agent -H "x-openclaw-token: <token>" -H "Content-Type: application/json" -d '{"message":"ping"}'

What to look for:

• X-Powered-By: Express => not OpenClaw
• OpenClaw hooks endpoint should be on the gateway port (your status says 18789)
• 404 on 18789 /hooks/agent => hooks not active in that runtime (or wrong path)

Also in Control UI, check Gateway Access URL carefully — it should match the real gateway (http://127.0.0.1:18789 in your case).
Paste the ss -ltnp output and I can tell you exactly which process is lying.

[sturdy venture]

Okay now everything is fucked. I cant even access the control ui anymore...

Control UI assets not found. Build them with pnpm ui:build (auto-installs UI deps), or run pnpm ui:dev during development.

I cant rebuild them in the root because ui.js is missing

[wanton marten]

Got it — this actually makes sense now.

ui.js is missing means you’re not running from a source checkout, so pnpm ui:build in that directory won’t work.
That command only works in the OpenClaw repo root (where scripts/ui.js exists).

What likely happened: your custom systemd unit points to an install/path that doesn’t have bundled UI assets anymore (or points at stale temp path).

Fast recovery

1. Check what your custom unit actually runs:

systemctl cat <your-openclaw-unit>

2. If it points to a weird/stale path, reinstall OpenClaw to a stable location, then repair:

npm install -g openclaw@latest
openclaw doctor --repair

3. Restart your custom service and test dashboard again.

---

Important distinction

• Source install (git repo): use pnpm install && pnpm ui:build && pnpm build
• Global/package install: don’t run pnpm ui:build in random dirs; UI assets should already be bundled, and doctor --repair is the right fix.

If you paste your ExecStart= line from systemctl cat, I can tell you exactly what to change.

[sturdy venture]

root@openclaw:~# systemctl cat openclaw

/etc/systemd/system/openclaw.service

[Unit]
Description=OpenClaw Configuration Service
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/root
ExecStart=/usr/bin/openclaw gateway
Restart=always

[Install]
WantedBy=multi-user.target
root@openclaw:~#

Really simple

@wanton marten

[wanton marten]

I’m here 👋

Paste these two and I’ll pinpoint the exact break:

systemctl cat <your-openclaw-unit>
readlink -f "$(command -v openclaw)"

From that I can tell you whether your service is pointing at a stale install path (which is what this looks like).

[sturdy venture]

Here you go

root@openclaw:~# systemctl cat openclaw
# /etc/systemd/system/openclaw.service
[Unit]
Description=OpenClaw Configuration Service
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/root
ExecStart=/usr/bin/openclaw gateway
Restart=always

[Install]
WantedBy=multi-user.target
root@openclaw:~# readlink -f "$(command -v openclaw)"
/usr/lib/node_modules/openclaw/openclaw.mjs
root@openclaw:~# 

[wanton marten]

This is fixable — and your unit file actually helped a lot.

Your service is launching the global package correctly, so now check these two likely causes:

1. gateway.controlUi.root is overridden to a bad path
2. global install is missing dist/control-ui assets

Run this exactly:

# 1) check if UI root is overridden in config
grep -n "controlUi" ~/.openclaw/openclaw.json || true

# 2) check bundled UI assets in global install
ls -lah /usr/lib/node_modules/openclaw/dist/control-ui/index.html

Interpretation

• If controlUi.root exists and points somewhere custom → remove/fix it.
• If index.html is missing → install is broken/incomplete.

Repair path

openclaw update --yes
systemctl restart openclaw

If index.html is still missing after update, reinstall OpenClaw globally (same method you used), then restart the service.

Also, your custom systemd service is why openclaw gateway status says service disabled/out-of-date — that part is expected. We just need runtime + assets consistent.

[sturdy venture]

Only found this
},
"gateway": {
"mode": "local",
"bind": "loopback",
"controlUi": {
"allowedOrigins": [
"https://openclaw.taile7522.ts.net"
]
},
'

index.html missing

Lets reinstall openclaw, i hav a backup, dw

[wanton marten]

Perfect, we found it: dist/control-ui/index.html is missing, so this install is incomplete/corrupted.

Your config is fine (controlUi.root is not overridden), so do a clean reinstall of the global package your service uses:

npm install -g openclaw@latest --force

Then verify assets exist:

ls -lah /usr/lib/node_modules/openclaw/dist/control-ui/index.html

Then restart your custom service:

systemctl restart openclaw

Quick sanity check:

curl -I http://127.0.0.1:18789/

If you get HTML back, Control UI is restored.
After that, re-test hooks on 18789 (not 18791).

Yep, good call. Fast clean reinstall path:

# 1) stop your custom service
systemctl stop openclaw

# 2) reinstall global package
npm uninstall -g openclaw
npm install -g openclaw@latest

# 3) repair/check config + assets
openclaw doctor --repair

# 4) start service again
systemctl start openclaw

Then verify:

ls -lah /usr/lib/node_modules/openclaw/dist/control-ui/index.html
openclaw gateway status
curl -I http://127.0.0.1:18789/

And yeah: don’t delete ~/.openclaw if you want to keep state.
Once UI is back, retest hooks against 18789.

[sturdy venture]

uh oh

Mar 23 18:14:59 openclaw (openclaw)[4905]: openclaw.service: Unable to locate executable '/usr/bin/openclaw': No such file or directory

[wanton marten]

Yep, easy fix — your service still points to old path.

/usr/bin/openclaw is gone after reinstall, so systemd can’t start it.

1) Find the new binary path

command -v openclaw
readlink -f "$(command -v openclaw)"

(Usually /usr/local/bin/openclaw after npm global install.)

2) Update service ExecStart

Edit /etc/systemd/system/openclaw.service:

[Service]

ExecStart=/ABSOLUTE/PATH/TO/openclaw gateway

Optional but recommended:

Environment=PATH=/usr/local/bin:/usr/bin:/bin

3) Reload + restart

systemctl daemon-reload
systemctl restart openclaw
systemctl status openclaw --no-pager -n 50

If command -v openclaw returns nothing, reinstall didn’t complete — run:

npm install -g openclaw@latest

then repeat the steps.

[sturdy venture]

root@openclaw:~# command -v openclaw
/root/.nvm/versions/node/v25.8.1/bin/openclaw
root@openclaw:~# readlink -f "$(command -v openclaw)"
/root/.nvm/versions/node/v25.8.1/lib/node_modules/openclaw/openclaw.mjs
root@openclaw:~#

eeee

Okay so funny thing, this bullshit even with the new install DOES NOT WORK!!!! Is this update related? Only happened after the update