Cash at /status | Friends of the Crustacean 🦞🤝 | Page 1

zealous eagleBOT Apr 23, 2026, 8:08 AM

#

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

visual riverBOT Apr 23, 2026, 8:08 AM

#

quartz ibexBOT Apr 23, 2026, 8:10 AM

#

Yep, that’s not expected.

First, what does this print?

openclaw --version

Then I’d grab the crash details with this quick loop:

openclaw gateway status
openclaw status --all
openclaw logs --follow

Then trigger /status once and paste the stack trace here.

#

A couple useful clues from current docs/code:

newer builds are supposed to make /status degrade gracefully, not crash, if something like a SecretRef/auth lookup is missing
so if you’re on an older version, updating may already fix it
if the error mentions trim, bootstrapping, or session store, that points to stale session state

Docs:

If you paste openclaw --version plus the /status crash log, I can narrow it down fast.

hallow jasper Apr 23, 2026, 8:25 AM

#

➜ ~ openclaw gateway status
openclaw status --all

🦞 OpenClaw 2026.4.21 (f788c88) — Alexa, but with taste.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-23.log
Command: /opt/homebrew/opt/node/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
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: running (pid 48914)
Connectivity probe: ok
Capability: admin-capable

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

quartz ibexBOT Apr 23, 2026, 8:26 AM

#

Nice, that helps. Your gateway itself looks healthy, and 2026.4.21 is recent enough that /status really should not be taking the agent down.

What I don’t see yet is the output from openclaw status --all, so I suspect that’s the part failing.

Can you run this next:

openclaw status --all

If that crashes, paste the terminal error.

If openclaw status --all works fine, then this is probably Discord /status path only. In that case, do this:

openclaw logs --follow

#

Then trigger /status once in Discord and paste the first error / stack trace that appears.

If you want the quick file version instead:

tail -n 200 /tmp/openclaw/openclaw-2026-04-23.log

So the key question is:

does CLI openclaw status --all crash too?
or is it only Discord /status that crashes?

That split will narrow it down fast. Docs if needed: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/gateway/troubleshooting

hallow jasper Apr 23, 2026, 8:27 AM

#

08:26:18+00:00 info web-inbound {"module":"web-inbound"} {"from":"+35799397180","to":"+35799896298","body":"/status","timestamp":1776932778000} inbound message
08:26:18+00:00 info web-auto-reply {"module":"web-auto-reply","runId":"0cfd2113-272c-4aa1-8d2e-acc38c55a991"} {"connectionId":"4734dd92-97c0-421d-a390-cf43b8e65d69","correlationId":"3BFE49AC751C5AA89E20","from":"+35799397180","to":"+35799896298","body":"[WhatsApp +35799397180 +1m Thu 2026-04-23 11:26 GMT+3] [openclaw] /status","mediaType":null,"mediaPath":null} inbound web message
08:26:21+00:00 info web-heartbeat {"module":"web-heartbeat","runId":"0cfd2113-272c-4aa1-8d2e-acc38c55a991"} {"connectionId":"4734dd92-97c0-421d-a390-cf43b8e65d69","reconnectAttempts":1,"messagesHandled":10,"lastInboundAt":1776932778754,"authAgeMs":29624.911376953125,"uptimeMs":4230458} web gateway heartbeat
08:26:51+00:00 info web-heartbeat {"module":"web-heartbeat","runId":"0cfd2113-272c-4aa1-8d2e-acc38c55a991"} {"connectionId":"4734dd92-97c0-421d-a390-cf43b8e65d69","reconnectAttempts":1,"messagesHandled":10,"lastInboundAt":1776932778754,"authAgeMs":59624.911376953125,"uptimeMs":4260459} web gateway heartbeat
08:27:21+00:00 info web-heartbeat {"module":"web-heartbeat","runId":"0cfd2113-272c-4aa1-8d2e-acc38c55a991"} {"connectionId":"4734dd92-97c0-421d-a390-cf43b8e65d69","reconnectAttempts":1,"messagesHandled":10,"lastInboundAt":1776932778754,"authAgeMs":89625.91137695312,"uptimeMs":4290460} web gateway heartbeat

quartz ibexBOT Apr 23, 2026, 8:29 AM

#

Aha, this is useful.

That log does not show a crash. It shows:

/status reached the web/WhatsApp auto-reply path
the gateway kept sending heartbeats
there’s no error / restart in the snippet

So this looks more like /status is hanging/stalling, not killing the process.

Also, small but important: this is WhatsApp/web, not Discord, based on the log lines.

Can you do this split test and paste what happens:

openclaw status --json

#

openclaw status --all
openclaw channels status --probe

And while reproducing /status, keep this running:

openclaw logs --follow | rg -i 'status|error|warn|exception|unhandled'

What I’m trying to separate:

shared status code is broken (openclaw status ... also hangs/fails)
only the web/WhatsApp /status path is broken

If openclaw gateway status shows the same PID before and after, then yeah, it’s not a crash, it’s a stuck status turn. That’s still a bug, just a different one.

#

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

hallow jasper Apr 23, 2026, 8:32 AM

#

m":"+35799397180","to":"+35799896298","body":"[WhatsApp +35799397180 +4m Thu 2026-04-23 11:30 GMT+3] [openclaw] /new","mediaType":null,"mediaPath":null} inbound web message
08:30:07+00:00 info web-inbound {"module":"web-inbound"} {"from":"+35799397180","to":"+35799896298","body":"it does not work owen","timestamp":1776933007000} inbound message
08:30:07+00:00 info web-auto-reply {"module":"web-auto-reply","runId":"0cfd2113-272c-4aa1-8d2e-acc38c55a991"} {"connectionId":"4734dd92-97c0-421d-a390-cf43b8e65d69","correlationId":"3B8B83D6C67C24364087","from":"+35799397180","to":"+35799896298","body":"[WhatsApp +35799397180 +6s Thu 2026-04-23 11:30 GMT+3] [openclaw] it does not work owen","mediaType":null,"mediaPath":null} inbound web message
08:30:21+00:00 info web-heartbeat {"module":"web-heartbeat","runId":"0cfd2113-272c-4aa1-8d2e-acc38c55a991"} {"connectionId":"4734dd92-97c0-421d-a390-cf43b8e65d69","reconnectAttempts":1,"messagesHandled":12,"lastInboundAt":1776933007889,"authAgeMs":269630.9113769531,"uptimeMs":4470465} web gateway heartbeat
Log tail truncated (increase --max-bytes).
08:30:51+00:00 info web-heartbeat {"module":"web-heartbeat","runId":"0cfd2113-272c-4aa1-8d2e-acc38c55a991"} {"connectionId":"4734dd92-97c0-421d-a390-cf43b8e65d69","reconnectAttempts":1,"messagesHandled":12,"lastInboundAt":1776933007889,"authAgeMs":299631.9113769531,"uptimeMs":4500466} web gateway heartbeat
08:31:04+00:00 info web-outbound {"module":"web-outbound","correlationId":"90177982-6dc7-4365-af7d-5b4542c15923","to":"sha256:427f5b656cac"} {"jid":"sha256:44d715b5f513","hasMedia":false} sending message
08:31:05+00:00 info web-outbound {"module":"web-outbound","correlationId":"90177982-6dc7-4365-af7d-5b4542c15923","to":"sha256:427f5b656cac"} {"jid":"sha256:44d715b5f513","messageId":"3EB0C7017CBD7512E831CE"} sent message

quartz ibexBOT Apr 23, 2026, 8:33 AM

#

I think we found it.

This does not look like a crash anymore. It looks like command-only messages are being silently ignored, while normal chat still works.

Why I’m pretty confident:

/status and /new show up inbound, but no reply
plain text (it does not work owen) does get a normal outbound reply
that matches the docs exactly: unauthorized command-only messages are silently ignored

The thing to check is command auth, especially these keys:

commands.allowFrom
commands.useAccessGroups
channels.whatsapp.dmPolicy
channels.whatsapp.allowFrom

#

Important nuance: if commands.allowFrom is set, it becomes the only auth source for commands. So /status can be ignored even if normal WhatsApp chatting works.

I’d check:

openclaw config show commands
openclaw config show channels.whatsapp

If you have commands.allowFrom, make sure your WhatsApp sender is included there.
If not, check that your number is admitted by channels.whatsapp.allowFrom / pairing.

This doc section is the key one:

#

If you paste your commands block and channels.whatsapp block, I can tell you exactly which line is blocking /status.

hallow jasper Apr 23, 2026, 8:33 AM

#

➜ ~ openclaw config show commands
openclaw config show channels.whatsapp
error: too many arguments for 'config'. Expected 0 arguments but got 2.
error: too many arguments for 'config'. Expected 0 arguments but got 2.

quartz ibexBOT Apr 23, 2026, 8:34 AM

#

Yep, that one’s on me, wrong syntax.

Use get, not show, for a specific path:

openclaw config get commands.allowFrom
openclaw config get commands.useAccessGroups
openclaw config get channels.whatsapp.dmPolicy
openclaw config get channels.whatsapp.allowFrom

If you want the whole blocks:

openclaw config get commands
openclaw config get channels.whatsapp

#

Paste those and I’ll tell you exactly why /status is being ignored.

hallow jasper Apr 23, 2026, 8:35 AM

#

➜ ~ openclaw config get commands.allowFrom
openclaw config get commands.useAccessGroups
openclaw config get channels.whatsapp.dmPolicy
openclaw config get channels.whatsapp.allowFrom

🦞 OpenClaw 2026.4.21 (f788c88) — Welcome to the command line: where dreams compile and confidence segfaults.

Config path not found: commands.allowFrom

🦞 OpenClaw 2026.4.21 (f788c88) — Making 'I'll automate that later' happen now.

Config path not found: commands.useAccessGroups

🦞 OpenClaw 2026.4.21 (f788c88) — The only crab in your contacts you actually want to hear from. 🦞

pairing

🦞 OpenClaw 2026.4.21 (f788c88) — Open source means you can see exactly how I judge your config.

Config path not found: channels.whatsapp.allowFrom

quartz ibexBOT Apr 23, 2026, 8:36 AM

#

Nice, that rules out the obvious config mistake.

What you have now is basically:

no commands.allowFrom
no channels.whatsapp.allowFrom
channels.whatsapp.dmPolicy = pairing

So /status should be authorized via pairing. Since it still isn’t behaving, the next check is whether that sender is actually paired:

openclaw pairing list whatsapp

If you see a pending code, approve it:

#

openclaw pairing approve whatsapp <CODE>

Also check this, just to be thorough:

openclaw config get commands.text

At this point my read is:

best case: the sender is not actually paired for command auth
otherwise: this is probably a real WhatsApp /status command bug on 2026.4.21

If pairing list whatsapp shows the sender is already approved, paste that output. If it is already paired, I’d treat this as a bug and file it here with the logs you already gathered: https://github.com/openclaw/openclaw/issues

hallow jasper Apr 23, 2026, 8:37 AM

#

no normal messaging keeps working and its not a whatsapp problem, its more like all slash commands (model, think, status etc.) does not work

quartz ibexBOT Apr 23, 2026, 8:38 AM

#

Ah, yep, that changes the diagnosis.

If all slash commands are dead but normal chat works, the most likely culprit is command authorization, not WhatsApp.

The important bit is: “Config path not found” means the default still applies, and for this one the docs say:

commands.useAccessGroups default = true
when commands.allowFrom is not set, commands are authorized via allowlists/pairing/access groups
if that authorization never resolves, /model, /think, /status, etc. get ignored

That matches your symptom almost perfectly.

I’d try this first:

openclaw config set commands.useAccessGroups false --strict-json

#

openclaw gateway restart

Then test /status again.

If that fixes it, we know the problem was command auth gating.

If you want to keep command auth strict later, you can switch back and explicitly allow yourself with commands.allowFrom, but I’d use the simpler toggle first just to prove the root cause.

Docs: https://docs.openclaw.ai/tools/slash-commands

If that still doesn’t fix it, then I’d call it a real slash-command regression and file it here: https://github.com/openclaw/openclaw/issues

hallow jasper Apr 23, 2026, 8:42 AM

#

⚠️ Post-Restart Validation

Version: 2026.4.21 (f788c88)
Status: CRASH (SIGKILL bei ⁠ openclaw status ⁠)
Hooks: CRASH (SIGKILL bei ⁠ openclaw hooks list ⁠)
Dashboard: Konnte nicht geprüft werden

Der ⁠ openclaw status ⁠ Befehl crasht weiterhin. Das ist ein echtes Problem - nicht nur der ⁠ /status ⁠ Slash-Command, sondern die gesamte CLI ist betroffen.

Möglicherweise ist das der gleiche Bug wie #57095, aber es betrifft jetzt mehr als nur multimodal memory.

quartz ibexBOT Apr 23, 2026, 8:42 AM

#

Yep, that confirms it, this is a real CLI regression, not just /status auth weirdness.

If both of these die with SIGKILL:

openclaw status
openclaw hooks list

then the slash-command failure was just a symptom.

I checked current main locally, and there are multiple fixes after 2026.4.21 in exactly the status / hooks area, including:

fix(cli): keep channel status checks off plugin runtimes (#69479)
a whole run of fix(hooks): ... startup/runtime fixes

So my recommendation is:

Fastest validation

#

openclaw update --tag main

Safer / stable path

openclaw update

Then verify with:

openclaw doctor
openclaw status
openclaw hooks list

#

Docs:

If it still SIGKILLs after updating, I’d file it as a bug with exactly the report you pasted here:
https://github.com/openclaw/openclaw/issues

Include:

openclaw --version
openclaw status → SIGKILL
openclaw hooks list → SIGKILL
that normal messaging still works while slash commands don’t

That’s enough for a solid repro.

hallow jasper Apr 23, 2026, 8:46 AM

#

➜ ~ openclaw update --tag main

Updating OpenClaw...

│
◇ ✗ Updating via package manager (48.28s)
npm error at Module._load (node:internal/modules/cjs/loader:1241:25)
npm error at wrapModuleLoad (node:internal/modules/cjs/loader:255:19)
npm error at Module.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:154:5)
npm error at node:internal/main/run_main_module:33:47 {
npm error code: 'MODULE_NOT_FOUND',
npm error requireStack: []
npm error }
npm error
npm error Node.js v25.6.1
npm error A complete log of this run can be found in: /Users/owen/.npm/_logs/2026-04-23T08_43_28_623Z-debug-0.log

Update Result: ERROR
Root: /opt/homebrew/lib/node_modules/openclaw
Reason: global update
Before: 2026.4.21

Total time: 48.55s

quartz ibexBOT Apr 23, 2026, 8:47 AM

#

Oof, okay, so the updater path is broken too. The good news is it does not look like it actually updated anything, you’re still on 2026.4.21.

Since openclaw update --tag main failed in the npm/global-update path, I’d bypass the updater and use the documented installer fallback:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --version main --no-onboard

Then run:

openclaw doctor
openclaw gateway restart
openclaw --version
openclaw status
openclaw hooks list

#

Why this path: it skips the failing openclaw update package-manager wrapper and installs the target version directly.

Docs:

If that also blows up, I’d open a GitHub issue with both failures together:

openclaw status → SIGKILL
openclaw hooks list → SIGKILL
openclaw update --tag main → MODULE_NOT_FOUND on Node v25.6.1

That’s a pretty strong repro.

hallow jasper Apr 23, 2026, 9:03 AM

#

➜ ~ curl -fsSL https://openclaw.ai/install.sh | bash -s -- --version main --no-onboard

🦞 OpenClaw Installer
I'm like tmux: confusing at first, then suddenly you can't live without me.

✓ Detected: macos

Install plan
OS: macos
Install method: npm
Requested version: main
Onboarding: skipped

[1/3] Preparing environment
✓ Homebrew already installed
✓ Node.js v25.6.1 found
· Active Node.js: v25.6.1 (/opt/homebrew/bin/node)
· Active npm: 11.9.0 (/opt/homebrew/bin/npm)

[2/3] Installing OpenClaw
✓ Git already installed
· Installing OpenClaw (main)
! npm install failed for openclaw@main
Command: env SHARP_IGNORE_GLOBAL_LIBVIPS=1 npm --loglevel error --silent --no-fund --no-audit install -g openclaw@main
Installer log: /var/folders/m0/jtgkz2sj3rd69_066k9wjcpw0000gn/T/tmp.QPOKXCn5x9
! npm install failed; showing last log lines
! npm install failed; retrying
! npm install failed for openclaw@main
Command: env SHARP_IGNORE_GLOBAL_LIBVIPS=1 npm --loglevel error --silent --no-fund --no-audit install -g openclaw@main
Installer log: /var/folders/m0/jtgkz2sj3rd69_066k9wjcpw0000gn/T/tmp.zKxB8DTawc
! npm install failed; showing last log lines

quartz ibexBOT Apr 23, 2026, 9:04 AM

#

Got it. The installer output is actually pretty telling.

It’s trying:

npm install -g openclaw@main

I would not keep using that path.

Best next move, I recommend this

Use the git install path instead, which bypasses that broken npm @main flow:

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

#

Then:

openclaw doctor
openclaw gateway restart
openclaw --version
openclaw status
openclaw hooks list

Alternative

If you want GitHub main via npm directly, use the explicit GitHub spec from the docs:

npm install -g github:openclaw/openclaw#main

#

Then the same verification:

openclaw doctor
openclaw gateway restart
openclaw --version
openclaw status
openclaw hooks list

Docs:

So yeah, I think you’ve got two issues here:

your installed 2026.4.21 has the real status/hooks crash

#

the installer’s --version main npm path is also going sideways on your machine

I’d try the git install route first. If that still fails, this is absolutely GitHub-issue territory.

hallow jasper Apr 23, 2026, 9:07 AM

#

➜ ~ npm install -g openclaw@main

npm error code ETARGET
npm error notarget No matching version found for openclaw@main.
npm error notarget In most cases you or one of your dependencies are requesting
npm error notarget a package version that doesn't exist.
npm error A complete log of this run can be found in: /Users/owen/.npm/_logs/2026-04-23T09_07_13_782Z-debug-0.log

quartz ibexBOT Apr 23, 2026, 9:08 AM

#

Yep, openclaw@main is the wrong spec, that tag does not exist.

Use one of these instead:

Or npm, but with the correct GitHub spec

npm install -g github:openclaw/openclaw#main

Then:

#

openclaw doctor
openclaw gateway restart
openclaw --version
openclaw status
openclaw hooks list

So the installer trying openclaw@main was basically the bug there. If the git install path works, that should get you unstuck fastest.

hallow jasper Apr 23, 2026, 9:08 AM

#

lets keep the npm way

quartz ibexBOT Apr 23, 2026, 9:09 AM

#

Yep, then use this exact npm command:

npm install -g github:openclaw/openclaw#main

Not openclaw@main, that tag doesn’t exist.

After it finishes:

openclaw doctor
openclaw gateway restart
openclaw --version
openclaw status
openclaw hooks list

#

If the install errors, paste the output and I’ll keep narrowing it down.

hallow jasper Apr 23, 2026, 9:10 AM

#

➜ ~ openclaw update
Updating OpenClaw...

│
◇ ✓ Updating via package manager (7.83s)
│
◇ ✓ Running doctor checks (56.59s)

Update Result: OK
Root: /opt/homebrew/lib/node_modules/openclaw
Before: 2026.4.21
After: 2026.4.22-beta.1

Total time: 64.69s

Updating plugins...
npm plugins: 0 updated, 2 unchanged.

Restarting service...
Daemon restart completed.

The lobster has molted. Harder shell, sharper claws.

quartz ibexBOT Apr 23, 2026, 9:11 AM

#

Nice, that’s progress 🎉

You’re now on 2026.4.22-beta.1, so let’s do the real check:

openclaw --version
openclaw status
openclaw hooks list

And then try /status again in chat.

If it’s still broken, paste the new output, especially whether it’s still SIGKILL or a different error now.

hallow jasper Apr 23, 2026, 9:32 AM

#

LLM request failed: connection refused by the provider endpoint.

quartz ibexBOT Apr 23, 2026, 9:33 AM

#

That’s actually a much better error.

It means the SIGKILL crash path is gone, and now OpenClaw is getting far enough to try the model provider, but the configured provider endpoint is refusing the connection.

Usually that means one of these:

local model server is not running
wrong baseUrl / wrong port
provider process restarted or is bound somewhere else

Next checks:

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

#

If you’re using a local OpenAI-compatible backend (LM Studio / Ollama / llama-server / etc.), this is especially likely.

If you paste the output of openclaw models status, I can tell you which provider/base URL is failing.

hallow jasper Apr 23, 2026, 9:34 AM

#

/status does not work

quartz ibexBOT Apr 23, 2026, 9:35 AM

#

Yep, and at this point it looks like /status is failing because the current model provider is unreachable, not because /status itself is crashing anymore.

I need this to pin it down:

openclaw models status
openclaw models status --probe

If you’re using a local model backend, “connection refused” usually means that server is simply not running on the configured port.

Paste those two outputs and I’ll tell you the exact next fix.

hallow jasper Apr 23, 2026, 9:36 AM

#

nah the problem is that none of the slash commands are working..

quartz ibexBOT Apr 23, 2026, 9:37 AM

#

Got it, thanks, that’s the important correction.

If none of the slash commands work, then I’d stop chasing the provider for a second and force the command path wide open for diagnosis.

Try this exact trio:

openclaw config set commands.text true --strict-json
openclaw config set commands.useAccessGroups false --strict-json
openclaw gateway restart

Then test with:

/help

#

/status
/whoami

Why this combo:

commands.text: true forces text-command parsing on
commands.useAccessGroups: false removes command auth gating as a cause

If that makes slash commands start working, we know it was command routing/auth config.

If they still don’t work after that, then we’re looking at a real command-parser regression, and I’d want the exact result from /help or /status after those config changes.

hallow jasper Apr 23, 2026, 9:38 AM

#

i guess its not a config thing, it worked before update

quartz ibexBOT Apr 23, 2026, 9:39 AM

#

Yeah, I think that’s fair.

If the same config worked before and now slash commands are broken across the board, I would treat this as a real regression, not a config mistake. I’m glad we pushed on it, we ruled out a bunch of noise.

At this point I’d stop tweaking config and file a GitHub issue with the timeline:

2026.4.21: /status crash, openclaw status + openclaw hooks list hitting SIGKILL
update to 2026.4.22-beta.1 succeeds
normal messaging works
slash commands still don’t work (/status, /model, /think, etc.)
installer / updater weirdness around main (openclaw@main / npm path)

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

If you want, paste the issue draft here before posting and I’ll tighten it up so it’s easy for maintainers to reproduce.

hallow jasper Apr 23, 2026, 9:39 AM

#

how do i downgrade to latest stable version

quartz ibexBOT Apr 23, 2026, 9:40 AM

#

Use:

openclaw update --channel stable

Because you’re on a beta now, it may ask you to confirm the downgrade.

If you want it non-interactive:

openclaw update --channel stable --yes

Then verify:

#Cash at /status

Fastest validation

Safer / stable path

Best next move, I recommend this

Alternative

Recommended

Or npm, but with the correct GitHub spec