WhatsApp channel always replies “Something went wrong…” after local setup (Windows, 2026.4.25)

[bitter moon]

I’ve spent a couple hours trying to get OpenClaw + WhatsApp working locally on Windows and I think I’m stuck on a channel handler bug, not config.

Setup:

Windows 11, OpenClaw 2026.4.25 (aa36ee6)

Gateway: local on 127.0.0.1:18789 (openclaw gateway status → reachable)

Model: Ollama (llama3.2:1b-instruct-q4_K_M at http://127.0.0.1:11434)

Workspace: C:\Users\15023\openclaw-workspace (set in agents.defaults.workspace)

BOOTSTRAP.md there with minimal instructions (“create/append MEMORY.md, log bootstrap completion, delete BOOTSTRAP.md, then continue”)

WhatsApp plugin enabled (stockwhatsappindex.js)

channels.whatsapp.enabled=true, selfChatMode=true, dmPolicy="allowlist"

What I’ve done:

openclaw onboard --mode local → chose Ollama + llama3.2:1b-instruct-q4_K_M.

Fixed earlier spawn git error so WhatsApp deps (@whiskeysockets/baileys, jimp) install.

openclaw gateway start → gateway reachable.

openclaw channels login --channel whatsapp --account default → scanned QR, saw:
“WhatsApp asked for a restart after pairing (code 515); waiting for creds to save…”

“✅ Linked after restart; web session ready.”

“Local login saved auth for whatsapp/default, but the running gateway did not restart it: gateway closed (1006 abnormal closure…).”

Restarted gateway; openclaw gateway run now says “Gateway already running; port 18789 is already in use.”

Problem:

From WhatsApp, any DM (even “hello from monica”) always gets:

“⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.”

This persists after restart; pairing clearly works but the handler always falls back to the generic error.

Agent config + workspace path + Ollama all look good; earlier bootstrap prompt leak is resolved, this is a new failure mode.

I have openclaw logs -- and can paste a snippet or share a paste link. Is this a known issue on 2026.4.25 for WhatsApp, or is there an extra step I missed to get past this “Something went wrong…” response?

[velvet ginkgo]

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

[signal plover]

I’d not call this a confirmed WhatsApp handler bug yet. Pairing + inbound accepted + a generic “Something went wrong…” usually means the message reached OpenClaw and the agent/model run failed before producing a reply. If allowlist/pairing were the problem, WhatsApp would usually block/pair, not run the agent. WhatsApp docs show the channel is Gateway-owned, DM-policy gated, and personal-number/self-chat mode depends on allowFrom + selfChatMode. (docs.openclaw.ai)

The big red flag is llama3.2:1b-instruct-q4_K_M. That’s very small for a full OpenClaw agent turn with bootstrap/context/tools. Docs explicitly warn smaller local backends can fail on the full agent prompt/tool schema; Ollama should also be using the native base URL with no /v1. (docs.openclaw.ai)

Try these to split “WhatsApp bug” vs “agent/model bug”:

openclaw infer model run --local --model ollama/llama3.2:1b-instruct-q4_K_M --prompt "Reply with exactly: pong" --json

Then full agent without WhatsApp:

openclaw agent --local --agent main --thinking off -m "Reply with exactly: AGENT_OK." --json

openclaw agent --local is the documented way to run an embedded agent turn directly, so if this fails too, it’s not WhatsApp. (docs.openclaw.ai)

For logs, please paste a redacted snippet around the first WhatsApp DM timestamp:

openclaw logs --limit 500 --plain --local-time

Redact phone numbers, tokens, QR/session/auth paths if needed. The useful line is usually near “Embedded agent failed before reply”, ollama, tool, timeout, schema, or bootstrap. openclaw logs supports --limit, --plain, and --local-time. (docs.openclaw.ai)

Fast workaround to test: enable lean local mode or switch temporarily to a stronger tool-capable model. If raw infer model run works but openclaw agent fails, that strongly points at local model/tool capacity rather than WhatsApp transport.

[bitter moon]

I think you’re right that it might not be a WhatsApp transport bug.

Quick recap of my setup in plain text:

Windows 11, OpenClaw 2026.4.25

Gateway local on 127.0.0.1:18789 and reachable (gateway status looks good)

Ollama at http://127.0.0.1:11434 using model: llama3.2:1b-instruct-q4_K_M

Workspace set to C:\Users\15023\openclaw-workspace in agents.defaults.workspace

WhatsApp plugin enabled, channel configured with dmPolicy="allowlist" and selfChatMode=true

BOOTSTRAP.md + workspace wiring is now correct; earlier bootstrap prompt leaks are gone

Current symptom:
From WhatsApp, any DM (even “hello from monica”) always gets:
"⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session."

So messages are clearly reaching the gateway, but the agent/model run fails before returning a reply.

Per your suggestion, my next steps are to:

Test the raw model via something like:
openclaw infer model run --local --model ollama/llama3.2:1b-instruct-q4_K_M --prompt "Reply with exactly: pong" --json

Test a full agent turn without WhatsApp via something like:
openclaw agent --local --agent main --thinking off -m "Reply with exactly: AGENT_OK." --json

[signal plover]

Yep, that plan is solid. I’d add one gateway-backed probe between the raw model test and the full WhatsApp path, because WhatsApp uses the running Gateway process/env:

openclaw infer model run --gateway --model ollama/llama3.2:1b-instruct-q4_K_M --prompt "Reply with exactly: pong" --json

Then:

openclaw agent --local --agent main --thinking off -m "Reply with exactly: AGENT_OK." --json

If those pass but WhatsApp still fails, try sending this in WhatsApp:

/verbose on

Then send hello from monica again. That should make the fallback expose the real “agent failed before reply” detail instead of only the generic message.

I checked quickly and I’m seeing similar OpenClaw issues around Ollama/local model agent failures — timeouts, unsupported tools, unknown model/context-window problems — not a clear “WhatsApp 2026.4.25 transport always broken” signal. (github.com)

If you paste the outputs of those 2–3 commands plus the nearby openclaw logs --limit 500 --plain --local-time lines, we can probably pin it down fast. Redact phone numbers/tokens/session paths.

[bitter moon]

Thanks, that’s super helpful, appreciate the concrete probes.

Plan I’m going to follow next:

Raw model via gateway (since WhatsApp goes through the running gateway):
openclaw infer model run --gateway --model ollama/llama3.2:1b-instruct-q4_K_M --prompt "Reply with exactly: pong" --json

Full agent turn without WhatsApp:
openclaw agent --local --agent main --thinking off -m "Reply with exactly: AGENT_OK." --json

If both of those succeed but WhatsApp still returns the generic “Something went wrong…” message, I’ll try turning on verbose mode in WhatsApp with:
/verbose on
and then send “hello from monica” again, to see if the fallback includes a more specific “agent failed before reply” error.

Once I’ve run those, I’ll grab:

the outputs of those infer/agent commands, and

nearby lines from:
openclaw logs --limit 500 --plain --local-time

(with phone numbers/tokens redacted) and drop them here so we can see whether this is an Ollama/local model issue (timeouts/tools/context window) vs something in the WhatsApp handler path.