Whatsapp Message Failure | Friends of the Crustacean 🦞🤝 | Page 1

floral flax Apr 20, 2026, 12:33 AM

#

Hi,

I have a user plugin at ~/.openclaw/extensions/whatsapp-tools/ that
should expose WhatsApp messaging as an LLM tool. It used to work -
I could tell my agent "send a message to +XXX" and it would send.
Now the agent hallucinates "message sent" without calling any tool.

Setup:

OpenClaw via Homebrew, macOS M1
Agent: Nina (claude-haiku-4-5-20251001)
WhatsApp extension: bundled, Baileys-based, paired and connected
Custom plugin: ~/.openclaw/extensions/whatsapp-tools/

Thanks!

untold quiverBOT Apr 20, 2026, 12:33 AM

#

plush lavaBOT Apr 20, 2026, 12:37 AM

#

First thing, what does openclaw --version print?

I checked current docs/code, and the most likely issue is that the WhatsApp tool is no longer in Nina’s effective tool list, even if the plugin itself still exists.

Two separate gates matter here:

Plugin load
- plugins.allow
- plugins.entries.<id>.enabled
- discovery from ~/.openclaw/extensions
Tool exposure
- tools.allow / agents.list[].tools.allow

And important bit: optional plugin tools are skipped unless explicitly allowlisted. They only load if tools.allow includes the tool name, the plugin id, or group:plugins.

Please check these:

#

openclaw --version
openclaw status --all
openclaw plugins list --verbose
openclaw plugins inspect whatsapp-tools
openclaw plugins doctor

If your tool is optional, make sure config includes something like:

{
  plugins: {
    entries: {
      "whatsapp-tools": { enabled: true }
    }

#

  },
  tools: {
    allow: ["whatsapp-tools"] // or the exact tool name
  }
}

If you already use plugins.allow, the plugin id must be in there too.

After any config/plugin change:

openclaw gateway restart

Then in the chat/session where Nina is running:

#

/verbose on
/trace on

Retry the send. If you see no tool bubble at all, the tool is not exposed. If the tool is exposed but Haiku still says “sent” without calling it, test once with a stronger tool-reliable model to separate policy/loading from model behavior.

Docs:

If you paste the output of openclaw --version + openclaw plugins inspect whatsapp-tools, I can narrow it down pretty fast.

floral flax Apr 20, 2026, 12:45 AM

#

Thanks for the debug commands. After running them, I found:

api.runtime.channels.whatsapp = undefined

The whatsapp-tools plugin loads BEFORE the whatsapp core
plugin, so runtime is not available during register().

I switched to lazy runtime access (access during execute()
instead of register()). But want to confirm:

Is there a way to declare plugin load order dependencies
in openclaw.plugin.json? (I tried "requires" - not in schema)
For user extensions in ~/.openclaw/extensions/, is lazy
runtime access the recommended pattern, or should I be
hooking into a different lifecycle event?
Is there an "onReady" or "afterInit" hook where all core
plugins are guaranteed loaded?

#

│ Item │ Value │
├──────────────────┼─────────────────────────────────────────────────────────┤
│ OpenClaw Version │ 2026.3.24 (cff6dc9) │
├──────────────────┼─────────────────────────────────────────────────────────┤
│ Plugin Status │ ✅ LOADED │
├──────────────────┼─────────────────────────────────────────────────────────┤
│ Plugin Source │ ~/.openclaw/extensions/whatsapp-tools/index.js │
├──────────────────┼─────────────────────────────────────────────────────────┤
│ Plugin Origin │ global (user extension) │
├──────────────────┼─────────────────────────────────────────────────────────┤
│ Shape │ non-capability │
├──────────────────┼─────────────────────────────────────────────────────────┤
│ Registered Tools │ send_whatsapp ✅ │
├──────────────────┼─────────────────────────────────────────────────────────┤
│ Warning │ loaded without install/load-path provenance (local │
│ │ code) │
├──────────────────┼─────────────────────────────────────────────────────────┤
│ plugins.allow │ empty (should add "whatsapp-tools") │

Key Finding: Tool IS registered (send_whatsapp listed), plugin IS loaded, but
warning shows plugins.allow is empty.

Fix needed: Add whatsapp-tools to plugins.allow in openclaw.json:

plush lavaBOT Apr 20, 2026, 12:53 AM

#

Yeah, your lazy execute() access is the right fix here.

Short answers:

Load-order deps in openclaw.plugin.json
- I don’t see a public dependency/load-order field for native plugins.
- openclaw.plugin.json is metadata/validation only, and "requires" is not part of the manifest schema.
- So, no supported “load WhatsApp before my plugin” declaration right now.
Recommended pattern for ~/.openclaw/extensions/
- Yes, lazy access is the safe pattern when you depend on another plugin’s runtime state.
- register() should assume other plugins may not be ready yet.
- Also, api.runtime.channel is the documented public channel runtime surface. api.runtime.channels.whatsapp looks like an internal reach-in, not a stable public contract.
onReady / afterInit
- I don’t see a documented plugin lifecycle hook with that name.
- The closest existing lifecycle hook is gateway_start, but I would treat that as a startup event, not as a cross-plugin dependency guarantee.

#

api.registrationMode ("full", "setup-only", "setup-runtime", "cli-metadata") is about load mode, not “all plugins are now ready”.

So the practical guidance is:

Do not rely on plugin registration order across different plugin ids
Do not depend on api.runtime.channels.whatsapp during register()
If you need WhatsApp behavior, either:
- resolve it inside execute(), or
- use a plugin-owned exported contract if the WhatsApp plugin exposes one, instead of reaching through core runtime internals

That lines up with current source too: the public runtime types explicitly avoid plugin-owned behavior hanging off core runtime slots like channel.discord / channel.slack.

Docs:

#

If you paste:

openclaw --version
your tool registration snippet
and the exact api.runtime.channels.whatsapp access

I can tell you the cleanest supported way to wire it.

Glad you found the real issue, that was a sneaky one. 🦐

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

#

I don’t think plugins.allow is the fix here.

From your own output:

Plugin Status: LOADED
Registered Tools: send_whatsapp ✅

So the plugin is already active. If plugins.allow were blocking it, you would not see it loaded with the tool registered.

That warning means:

security / provenance warning
“this is local untracked code, pin trust explicitly if you want”

It does not mean “plugin failed to load”.

So I’d separate the two:

#

What is actually fixing the bug

your change to lazy runtime access in execute()
or moving to a proper exported contract instead of reaching into api.runtime.channels.whatsapp

What `plugins.allow` would do

explicitly trust whatsapp-tools
reduce accidental auto-loading of local plugins
good hardening, but not the cause of this runtime-order issue

So the blunt version is:

Yes, adding "whatsapp-tools" to plugins.allow is reasonable hygiene.
No, it is probably not why the tool was hallucinating.

If the agent is still saying “sent” without a tool call after your lazy-runtime fix, then the next place I’d look is the agent’s effective tool policy, not plugin loading:

tools.allow
agents.list[].tools.allow

#

/verbose on
/trace on

But based on what you found, the main bug still looks like cross-plugin runtime timing during register(), not plugins.allow.

If you want, paste the send_whatsapp registration + execute() snippet and I’ll sanity check the exact pattern.

floral flax Apr 20, 2026, 12:59 AM

#

✅ Lazy execute() = correct pattern (api.runtime access at execution time,
not register time)
❌ api.runtime.channels.whatsapp = internal, not public API
❌ plugins.allow ≠ cause of the issue (plugin already loaded + tool
registered)
✅ Use proper exported contract instead of reaching into core runtime
internals

Current Implementation

  // CURRENT (reaching into internal api.runtime.channels.whatsapp):           
  async execute(_toolCallId, params) {                                         
    const waRuntime = api.runtime?.channels?.whatsapp;                         
    if (!waRuntime) return { ... error ... };                                  
    const result = await waRuntime.sendMessageWhatsApp(ji d, params.message);  
    return { ... success ... };                                                
  }

Problem: api.runtime.channels.whatsapp is internal, unstable.

If there's a documented way for plugins to request WhatsApp sends

plush lavaBOT Apr 20, 2026, 1:01 AM

#

Yeah, this is the key distinction:

If you want the agent to send WhatsApp messages

The canonical path is the shared message tool, not a custom WhatsApp-specific tool.

That’s the documented design:

core owns one shared message tool
channel plugins, including WhatsApp, provide the channel-specific execution behind it

Docs: https://docs.openclaw.ai/plugins/architecture#channel-plugins-and-the-shared-message-tool

If you want plugin code to send via WhatsApp programmatically

I do not see a documented public api.runtime.whatsapp.send(...) style API.

So I would not keep using:

#

api.runtime.channels.whatsapp

That’s an internal reach-in.

Best current pattern

If you must do this inside plugin code, the cleanest abstraction is the channel outbound adapter, not WhatsApp internals:

async execute(_toolCallId, params) {
  const outbound = await api.runtime.channel.outbound.loadAdapter("whatsapp");
  if (!outbound?.sendText) {
    throw new Error("WhatsApp outbound adapter unavailable");
  }

#

  const cfg = api.runtime.config.loadConfig();

  const result = await outbound.sendText({
    cfg,
    to: params.to,
    text: params.message,
    accountId: params.accountId ?? null,
  });

  return {
    content: [
      { type: "text", text: `Sent WhatsApp message to ${params.to}` },
    ],
  };
}

#

That keeps you on the channel abstraction instead of api.runtime.channels.whatsapp.

What I would avoid

api.runtime.channels.whatsapp
importing WhatsApp src/*
coupling a third-party plugin directly to bundled WhatsApp internals

Practical recommendation

If this is just “let the model send WhatsApp”, use the built-in message tool instead.
If you need custom validation / target resolution, keep your custom tool, but send through the outbound adapter.

If you want, paste your actual send_whatsapp tool and I’ll rewrite it to the adapter pattern.

floral flax Apr 20, 2026, 7:05 AM

#

Dear, problem still presist, please give me a step by step guide for troubleshooting, this is very important for me to tell my agent to send "x message" to "x number"

plush lavaBOT Apr 20, 2026, 7:06 AM

#

That’s frustrating. Let’s make this mechanical and isolate exactly where it breaks.

Step 1, restart after any plugin code change

Run:

openclaw gateway restart
openclaw plugins inspect whatsapp-tools
openclaw status --all

What you want to see:

whatsapp-tools is still LOADED
send_whatsapp is still listed
WhatsApp channel looks healthy / connected

#

Step 2, watch logs live during one test

In a second terminal, run:

openclaw logs --follow

Leave that running.

Step 3, turn on tool visibility in the agent chat

In Nina’s chat, run:

/verbose on

#

/trace on

Now every test should make it much clearer whether a real tool call happened.

Step 4, test the built-in path first

This is important, because it tells us whether WhatsApp itself is fine.

Send Nina this exact instruction:

Use the message tool with action="send", channel="whatsapp", target="+<number>", message="built-in WhatsApp test". Do not say it was sent unless the tool returns success.

#

Result interpretation

If this works: WhatsApp outbound is fine. Your custom plugin is the problem.
If this fails: the issue is lower level, WhatsApp channel / outbound path, not your custom tool.

Step 5, test your custom tool directly

Now test your plugin tool with a very explicit prompt:

Call the send_whatsapp tool now with the exact target "+<number>" and message "custom tool test". Do not answer normally. Only use the tool.

Result interpretation

If Nina replies normally and no tool call appears: the tool is not in Nina’s effective tool list, or the model is not actually choosing it.
If the tool call appears and errors: your plugin code is being reached, and we debug the execute path.
If the tool call appears and succeeds: the plumbing is fine, and the remaining issue is prompt / tool-choice behavior.

#

Step 6, if the custom tool is called but still fails

Then the next thing to fix is the implementation.

For your plugin, do not use:

api.runtime.channels.whatsapp

That is the unstable internal reach-in.

Short-term safest options:

Best: stop using the custom tool and rely on the built-in message tool
If you keep the plugin: send through the channel abstraction, not WhatsApp internals

#

Step 7, if no custom tool call happens at all

Then check the agent’s effective tool policy.

Look at:

tools.allow
tools.deny
agents.list[].tools.allow
whether send_whatsapp was registered as optional

Important nuance:

plugins.allow is not the root cause here if the plugin already shows as loaded.
But tool allowlists absolutely can prevent the agent from seeing or using send_whatsapp.

#

Step 8, what to paste back here

If it still fails, paste these 3 things only:

Output of:

openclaw plugins inspect whatsapp-tools

The exact agent reply from:

built-in message tool test
custom send_whatsapp test

The matching openclaw logs --follow lines from that test window

If you send me those 3 pieces, I can usually tell you exactly which layer is broken within one pass.

floral flax Apr 20, 2026, 7:09 AM

#

nina replies normally when I text normally on whatapp, or in group chats works perfectly fine, the only problem is it works reactive not proactive as I need it

plush lavaBOT Apr 20, 2026, 7:10 AM

#

That’s actually helpful, because it narrows it down a lot.

If Nina replies normally in WhatsApp already, then the WhatsApp channel itself is working.
So the problem is now almost certainly proactive outbound targeting, not pairing or Baileys.

Do this next, in this exact order

1. Test proactive send without the agent

Run this from terminal:

openclaw message send --channel whatsapp --target +<number> --message "proactive test"

Docs: https://docs.openclaw.ai/cli/message

2. Watch the result carefully

#

If it fails with something like:

Target "+<number>" is not listed in the configured WhatsApp allowFrom policy.

then you found the problem.

Reactive replies work because Nina is replying inside an existing allowed conversation.
Proactive sends to a new target go through WhatsApp outbound target policy.

The key config is:

channels.whatsapp.allowFrom
or, if multi-account, channels.whatsapp.accounts.<id>.allowFrom

For a quick test, temporarily allow all:

#

{
  channels: {
    whatsapp: {
      allowFrom: ["*"],
    },
  },
}

Then:

openclaw gateway restart

If multi-account, set it on the account block instead.

#

WhatsApp docs: https://docs.openclaw.ai/channels/whatsapp

3. If the CLI proactive send works

Then WhatsApp proactive outbound is fine, and the remaining problem is agent/tool routing.

At that point, test Nina with the built-in tool path:

Use the message tool with action="send", channel="whatsapp", target="+<number>", message="agent proactive test". Do not claim success unless the tool returns success.

Result:

works → your custom plugin is the issue
does not call the tool → Nina’s effective tool list / tool-choice path is the issue

#

4. If built-in message tool works

Then honestly, the fastest fix is:

stop using the custom send_whatsapp plugin tool
let Nina use the built-in message tool for proactive sends

That is the supported path.

My best guess right now

Because reactive works but proactive does not, I’m pretty suspicious of allowFrom blocking the new target number.

So I’d start with this one command first:

#

openclaw message send --channel whatsapp --target +<number> --message "proactive test"

If you paste the exact output of that command, I can tell you the next step immediately.

floral flax Apr 20, 2026, 7:18 AM

#

% openclaw message send --channel whatsapp --target +xx --message "proactive test" method worked

plush lavaBOT Apr 20, 2026, 7:18 AM

#

Perfect, that’s the key result. 🎉

That means:

WhatsApp proactive outbound works
Baileys / listener / allowFrom are fine
the bug is now only in the agent tool path, not the channel

What to do now

Fastest fix

Stop debugging the custom WhatsApp tool for the moment, and make Nina use the built-in message tool.

In Nina’s chat, test this exact prompt:

#

Use the message tool with action="send", channel="whatsapp", target="+xx", message="hello from Nina". Do not say it was sent unless the tool returns success.

If that works

Then you already have your solution:

remove or ignore send_whatsapp
rely on the built-in message tool for proactive sends

That is the supported path, and it avoids the custom-plugin weirdness entirely.

If Nina still replies normally and does not call the tool

Then the problem is tool exposure / tool choice for Nina.

Check these next:

#

turn on:
```
/verbose on
/trace on
```
if you use tool allowlists, make sure Nina can access:
- message

If message is not available to Nina, she will just free-text “sent” instead of actually sending.

My recommendation

Honestly, since:

proactive CLI send works, and
the custom plugin has already been flaky,

#

I would ditch the custom send_whatsapp tool and use the built-in message tool instead.

That gets you to the real goal, “tell my agent to send x message to x number”, with much less pain.

If you want, send me the result of the built-in message tool test next, and I’ll tell you the final config change if Nina still doesn’t call it.

floral flax Apr 20, 2026, 7:41 AM

#

Thanks for your help and support! I still need to move forward with trouble shootingi, please keep in mind im not a developer, give me simple and easy steps

plush lavaBOT Apr 20, 2026, 7:42 AM

#

Absolutely, let’s keep it simple.

Good news

You already proved the hard part:

WhatsApp itself works
proactive sending works
the issue is only getting Nina to use the right tool

So for now, ignore the custom plugin. We don’t need it for this test.

Simple next steps

Step 1

Open your chat with Nina.

Step 2

#

Send this:

/verbose on

Step 3

Then copy and paste this exact message to Nina:

Use the message tool with action="send", channel="whatsapp", target="+xx", message="hello from Nina". Do not say it was sent unless the tool returns success.

What should happen

If it works

Great, you’re done with the main problem.

#

That means Nina can send proactive WhatsApp messages using the built-in tool.

If it does NOT work

Just paste back exactly what Nina says.

That’s all I need for the next step.

Important

For now:

do not use the custom send_whatsapp plugin
test only the built-in message tool

That gives us the clearest answer.

If you want, do Step 2 + Step 3 now and paste Nina’s exact reply here.

floral flax Apr 20, 2026, 7:44 AM

#

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

what could be causing this error

plush lavaBOT Apr 20, 2026, 7:45 AM

#

That error usually means Nina failed before she could reply.

So this is not a WhatsApp sending problem anymore, because you already proved WhatsApp can send proactively from the terminal.

Most likely causes

Usually one of these:

temporary model/API failure
Nina does not have access to the message tool
the current Nina chat/session got stuck
the custom plugin setup is still interfering

Keep it simple, do these 3 steps

Step 1

Restart the gateway:

#

openclaw gateway restart

Step 2

Open a fresh Nina chat and send this simpler message:

Send "hello" to +xx on WhatsApp using the message tool.

Step 3

If you get the same error again, run this in terminal:

openclaw logs --follow

#

Then try the same message one more time, and paste the new error lines here.

Important

At this point, the log output is the thing that will tell us the truth.

Because right now:

WhatsApp works
proactive sending works
the failure is happening inside Nina’s agent run

If you want, do Step 1, then Step 2 once, and if it still fails send me the openclaw logs --follow output.

floral flax Apr 20, 2026, 9:59 AM

#

Please suggest me the best setup for a 100% proper working Whatsapp Agent,

1- it should be able to send my desired message to desired number or group chat in whatsapp.

2- it should work proactively and shall not wait for a message to respond.

3- it should be able to transfer me all the chat logs, questions etc.
it should work as a bridge between me and my contacts.

My current setup is working fine when my agent works in chats and also groups its fine. but

Please ask me any questions you like to help me troubleshoot, feel free to

plush lavaBOT Apr 20, 2026, 10:02 AM

#

I can help, but I want to set expectations clearly: there is no real 100% setup.
For WhatsApp, the most reliable setup is this:

Best setup I recommend

1. Use the built-in WhatsApp path, not your custom plugin

Your custom whatsapp-tools plugin is probably adding confusion here.

For reliability, use:

exact send: openclaw message send
proactive agent run: openclaw agent --deliver
normal chat replies: built-in WhatsApp channel

Docs:

#

https://docs.openclaw.ai/channels/whatsapp

2. Keep proactive sending separate from normal chat replying

Use these two patterns:

Send an exact message to a person/group

openclaw message send --channel whatsapp --target +15555550123 --message "Hello"

Ask the agent to generate and deliver a proactive message

openclaw agent --to +15555550123 --message "Send a polite follow-up" --deliver

That second one is the cleanest way to do proactive outbound.

#

3. Use a separate admin chat for yourself

If you want the agent to act like a bridge, the cleanest setup is:

WhatsApp number A = the agent talking to your contacts
admin chat = where the agent sends summaries, questions, alerts, approvals

That admin chat can be WhatsApp, Telegram, or Discord.
This is much more reliable than trying to make one chat do everything.

4. Keep transcripts on disk

OpenClaw stores session transcripts here:

~/.openclaw/agents/<agentId>/sessions/

Docs: https://docs.openclaw.ai/concepts/agent-workspace

#

So for your goal #3, there are really two versions:

A. saved transcripts on disk → already supported
B. live forwarding of all chats to you → possible as a workflow, but I’d design that carefully instead of treating it like a default bridge

5. Use a stronger model if reliability matters

Smaller/cheaper models are more likely to:

skip tools
hallucinate “message sent”
fail on structured tool calls

For the most reliable tool use, check:

https://docs.openclaw.ai/concepts/models
ask in #models for the current best tool-reliable choice

My recommendation for your goals

If I were setting this up for reliability, I would do this:

#

one dedicated WhatsApp number for the agent
one dedicated OpenClaw agent
no custom WhatsApp plugin
built-in message tool for sends
openclaw agent --deliver for proactive outreach
a separate admin chat where the agent sends you summaries/questions

That is the least fragile setup.

3 questions for you

Please answer these, and then I can give you the exact next steps:

What does this print?

openclaw --version

#

Are you okay removing/ignoring the custom ~/.openclaw/extensions/whatsapp-tools/ plugin for now?
For “bridge between me and my contacts”, do you want:
- only summaries/questions sent to you, or
- every incoming and outgoing message mirrored to you live?

If you answer those 3, I’ll give you the simplest recommended setup for your case.

floral flax Apr 20, 2026, 10:12 AM

#

can you provide me a promt that my agent will handle it? Im truly running out of patience on this

plush lavaBOT Apr 20, 2026, 10:13 AM

#

Yeah, let’s cut through it.

1. Put this in Nina’s instructions / system prompt

You handle WhatsApp sending through the built-in message tool.

Rules:
1. When the user asks to send a WhatsApp message, always use the message tool.
2. Use:
   - action: "send"
   - channel: "whatsapp"
   - target: the phone number in E.164 format (+15555550123) or the WhatsApp group id
   - message: the exact text to send
3. Never claim a message was sent unless the tool returns success.
4. If target or message is missing, ask for the missing part.

#

5. Do not wait for an inbound message before sending. Proactive sending is allowed.
6. Do not use any custom WhatsApp tool if the built-in message tool is available.

2. Then send Nina this exact prompt when you want a message sent

Send a WhatsApp message now using the message tool.

Target: +xx
Message: hello, this is a proactive test

Do not say it was sent unless the tool succeeds.

3. Even stronger version

#

If Nina still wiggles out of it, use this:

You must call the message tool right now with:
- action: send
- channel: whatsapp
- target: +xx
- message: hello, this is a proactive test

If the tool fails, show the error. Do not pretend success.

Important

If Nina still hallucinates after this, then the problem is probably not the prompt anymore.
It means one of these is wrong:

the message tool is not available to Nina

#

the model is weak at tool use
the agent session is broken

But try the prompt above first, because it’s the cleanest test.

If you want, after you try it, paste Nina’s exact reply and I’ll give you the next shortest fix.

floral flax Apr 20, 2026, 10:16 AM

#

Message from Nina

I apologize — I don't actually have the message tool available in my runtime.
Looking at my available tools, I have: exec, process, read, write, edit, grep,
find, ls, apply_patch, browser, canvas, nodes, cron, sessions_list,
sessions_history, sessions_send, subagents, session_status, and a few others —
but no native message tool.

Let me use the exec approach instead to send via the CLI:

plush lavaBOT Apr 20, 2026, 10:17 AM

#

Aha, we found the real problem.

Root cause

Nina does not have the message tool enabled.

So this is why she keeps failing or trying weird workarounds.

Also, from the tool list she showed, I strongly suspect Nina is using the coding tool profile, which includes things like exec, read, write, browser, etc. but does not include message.

Docs: https://docs.openclaw.ai/tools/index

Best simple fix

If Nina is mainly for WhatsApp / chat / bridge use

Set Nina to:

#

tools: {
  profile: "messaging"
}

That profile includes the message tool.

If you want Nina to have everything

Set Nina to:

tools: {
  profile: "full"
}

#

That gives all built-in tools, including message.

Where to change it

Open your config file:

~/.openclaw/openclaw.json

Find Nina’s agent block and change it to something like this:

{
  "agents": {

#

    "list": [
      {
        "id": "nina",
        "name": "Nina",
        "tools": {
          "profile": "messaging"
        }
      }
    ]
  }
}

If Nina already has a tools section, just change the profile there.

Important

#

If you have a global setting like this:

tools: {
  profile: "coding"
}

that may be the reason message disappeared.

In that case, keep the global setting if you want, but override Nina specifically with:

tools: {
  profile: "messaging"
}

#

The agent-specific profile should win.

Docs: https://docs.openclaw.ai/tools/multi-agent-sandbox-tools

Then do this

After saving the config:

openclaw gateway restart

Then test Nina again with:

Send a WhatsApp message to +xx saying: hello from Nina

#

My recommendation

For your use case, I would use:

profile: "messaging" for Nina
no custom WhatsApp send plugin
built-in message tool only

That is the cleanest setup.

If you want, paste your Nina config block here and I’ll tell you exactly what line to change.

floral flax Apr 20, 2026, 10:42 AM

#

Message test successful! Now it has issues with whitelisting new numbers

plush lavaBOT Apr 20, 2026, 10:43 AM

#

Nice, that’s real progress. 🎉

That means the agent/tool problem is fixed.
Now you’re just hitting WhatsApp access policy.

What controls new numbers

This setting:

channels.whatsapp.allowFrom

Docs: https://docs.openclaw.ai/channels/whatsapp

Easiest choices

Option A, easiest, any new number works

If this is a dedicated WhatsApp number for the agent, use:

#

{
  channels: {
    whatsapp: {
      dmPolicy: "open",
      allowFrom: ["*"]
    }
  }
}

Then restart:

openclaw gateway restart

#

Option B, safer, manual whitelist

If you only want approved numbers:

{
  channels: {
    whatsapp: {
      dmPolicy: "allowlist",
      allowFrom: [
        "+11111111111",
        "+22222222222"
      ]
    }
  }
}

#

Then every new number must be added there.

Option C, middle ground

If you want people to message first, then approve them:

{
  channels: {
    whatsapp: {
      dmPolicy: "pairing"
    }
  }
}

Then approve new people with:

#

openclaw pairing list whatsapp
openclaw pairing approve whatsapp <CODE>

My recommendation for your use case

Because you want:

proactive outbound
bridge behavior
new numbers to work easily

I would use:

a separate WhatsApp number
dmPolicy: "open"
allowFrom: ["*"]

#

That is the least painful setup.

Important note

If you use your personal WhatsApp number, I would not open it to ["*"].

That’s better only for a dedicated agent number.

If you want, paste your current channels.whatsapp config block here and I’ll rewrite it for the exact behavior you want.

floral flax Apr 20, 2026, 10:47 AM

#

it says target not listed? can you please provide me a basic troubleshooting promt?

plush lavaBOT Apr 20, 2026, 10:48 AM

#

Yep, that specific error means:

the phone number you’re trying to message is not in channels.whatsapp.allowFrom

Quick fix

Allow only one number

{
  channels: {
    whatsapp: {
      dmPolicy: "allowlist",
      allowFrom: ["+xx"]
    }
  }
}

#

Allow any number

{
  channels: {
    whatsapp: {
      dmPolicy: "open",
      allowFrom: ["*"]
    }
  }
}

Then restart:

openclaw gateway restart

#

Basic troubleshooting prompt for Nina

Copy/paste this:

Do not send anything yet.

I got this WhatsApp error:
Target is not listed in the configured WhatsApp allowFrom policy.

Please explain in simple words:
1. what this error means
2. whether I should change channels.whatsapp.allowFrom
3. the exact config for:
   - allowing only one number: +xx

#

   - allowing any number
4. remind me to restart the gateway after editing config

Do not use exec workarounds. Do not pretend success.

Even simpler

If you just want the shortest version for Nina:

Explain how to fix this WhatsApp error in simple words:
Target is not listed in allowFrom.
Show me the exact config change.

If you want, paste your current channels.whatsapp block and I’ll rewrite it correctly for you.

floral flax Apr 20, 2026, 10:53 AM

#

WhatsApp is blocking messages to +905488550000 because that number isn't in the "allowed list" in your config file.

The Fix (Exact Config Change):

Open ~/.openclaw/openclaw.json and find the channels.whatsapp section.

Current (broken):
json
{
"channels": {
"whatsapp": {
"enabled": true,
"allowFrom": [
"+905488752525",
"+905338841495",
"+905428882929",
"+905338866418"
]
}
}
}

Fixed (add Durdu's number):
json
{
"channels": {
"whatsapp": {
"enabled": true,
"allowFrom": [
"+905488752525",
"+905338841495",
"+905428882929",
"+905338866418",
"+905488550000"
]
}
}
}

What changed: Added "+905488550000" (Durdu Bey's number) to the list.

After you save:
bash
openclaw gateway restart

Then try sending again. Should work now. ✅

plush lavaBOT Apr 20, 2026, 10:53 AM

#

Yep, that answer is basically correct.

What to do

add the new contact to channels.whatsapp.allowFrom
save ~/.openclaw/openclaw.json
run:

openclaw gateway restart

Then test again.

One important note

If you use multi-account WhatsApp, the allowlist may need to go here instead:

#

channels.whatsapp.accounts.<accountId>.allowFrom

not just the top-level channels.whatsapp.allowFrom.

Privacy note

You pasted real phone numbers into the thread. I’d strongly recommend editing/redacting those numbers.

If you want less manual work later

If this is a dedicated agent WhatsApp number, you can switch to:

dmPolicy: "open",
allowFrom: ["*"]

#

That stops the “target not listed” problem for new contacts.

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

floral flax Apr 20, 2026, 10:55 AM

#

Gateway restart sonrası henüz Durdu'ya mesaj gönderme testi yapılmadı. allowFrom policy cache issue var hâlâ.

Durumu:

✅ Config güncellendi
✅ Gateway restarted
⏳ Policy cache çözümü beklemede (community support)
🔄 Test hazır, cevap gelince çalıştırırız

Support answer geldiğinde hemen deneyeceğiz. 🎯

plush lavaBOT Apr 20, 2026, 10:56 AM

#

Bu bana cache issuedan çok config scope/override gibi geliyor.

Özellikle şu 2 şey en sık sebep oluyor:

multi-account kullanıyorsan yanlış yere ekliyorsun
Doğru yer bazen şurası oluyor:
```
channels.whatsapp.accounts.<accountId>.allowFrom
```
sadece top-level channels.whatsapp.allowFrom yetmeyebiliyor.
openclaw.json içinde aynı key ikinci kez var
JSON5’te later entry earlier entry’yi override eder.
Yani bir yerde ekliyorsun, başka yerde eski liste tekrar yazıp üstüne basıyor.

Ben olsam şimdi bunu yapardım

#

1. Hedef numarayı doğru formatta kontrol et

Tam E.164 olsun:

+90...

2. Config’te tek bir WhatsApp bloğu kaldığından emin ol

Şunları kontrol et:

channels.whatsapp.allowFrom
channels.whatsapp.accounts
ikinci bir channels.whatsapp bloğu var mı
Nina başka account’tan mı gönderiyor

3. Multi-account varsa account override’a ekle

Örnek:

#

{
  channels: {
    whatsapp: {
      accounts: {
        default: {
          allowFrom: ["+90..."]
        }
      }
    }
  }
}

4. Sonra restart

#

openclaw gateway stop
openclaw gateway start

Sonra tekrar test:

openclaw message send --channel whatsapp --target +90... --message "test"

Kısa teşhis promptu

Bunu Nina’ya ver:

Do not send anything yet.

#


I still get: Target is not listed in the configured WhatsApp allowFrom policy.

Please help me troubleshoot in simple steps.
Check these possibilities only:
1. wrong allowFrom location
2. multi-account override
3. duplicate whatsapp config block
4. number format problem

Tell me the most likely cause first.
Do not pretend success.

En muhtemel gerçek sebep

Config güncel + restart yapılmış ama hata sürüyorsa, bence en olası sebep:

#

wrong account
veya duplicate/overridden allowFrom

İstersen channels.whatsapp kısmını, numaraları gizleyerek, buraya yapıştır. Ben sana direkt hangi satırı değiştirmen gerektiğini söyleyeyim.

floral flax Apr 20, 2026, 11:05 AM

#

EOF

Gateway restart ettim. Şimdi mesaj:Aynı sorun. allowFrom cache'de takılı. Her yeni numara eklendiğinde bu error geliyor — policy cache reset olmuyor.

Bu konuda support'tan cevap gerekiyor. Whitelist sistem düzgün çalışmıyor, yeni numaraları config'e eklemeye rağmen rejectediliyor.

plush lavaBOT Apr 20, 2026, 11:06 AM

#

Olabilir, ama bunu cache bug diye kapatmadan önce yapabileceğin tek net test var.

Kesin teşhis testi

Geçici olarak bunu yap:

{
  channels: {
    whatsapp: {
      dmPolicy: "open",
      allowFrom: ["*"]
    }
  }
}

#

Sonra:

openclaw gateway stop
openclaw gateway start

ve tekrar dene.

Bu test bize ne söyleyecek?

Eğer yine `target not listed` diyorsa

Bu durumda sorun büyük ihtimalle:

yanlış config scope
multi-account override
duplicate channels.whatsapp block

#

yanlış dosya editleniyor

Yani bu durumda ben hâlâ cache değil, effective config mismatch derim.

Eğer bu çalışırsa

O zaman runtime config reload olmuş demektir.
Sorun cache değil, büyük ihtimalle:

yanlış allowFrom listesi
yanlış account
number format / override

Support’a göndermek için 3 net çıktı

Bunları paylaş, o zaman gerçekten support-level diagnosis olur:

#

openclaw --version
openclaw config get channels.whatsapp --json
openclaw config get channels.whatsapp.accounts --json

ve ayrıca şu testin exact output’u:

openclaw message send --channel whatsapp --target +90... --message "test"

Benim dürüst görüşüm

Şu an gördüğüm tablo bana policy cache bugdan çok
wrong effective config gibi görünüyor.

Çünkü allowFrom: ["*"] ile bile aynı hata devam ederse, runtime senin değiştirdiğin bloğu hiç kullanmıyor demektir.

#

İstersen bir sonraki mesajda sadece şunları at:

openclaw --version
openclaw config get channels.whatsapp --json
openclaw config get channels.whatsapp.accounts --json

Ben sana direkt nerede override olduğunu söyleyeyim.

#

Please ignore that link. It is not an official OpenClaw support path, and I would not enter anything there.

For maintainer attention, use GitHub issues only:
https://github.com/openclaw/openclaw/issues

If you file it, include these 4 things:

openclaw --version
openclaw config get channels.whatsapp --json
openclaw config get channels.whatsapp.accounts --json
openclaw message send --channel whatsapp --target +90... --message "test"

And mention:

WhatsApp outbound works for already-allowed numbers

#

new numbers still fail with target not listed
gateway restart did not change behavior

If you want, paste the redacted outputs here first and I’ll help you tighten the bug report.

floral flax Apr 20, 2026, 11:07 AM

#

is there any real person that can help me? Im really stuck

plush lavaBOT Apr 20, 2026, 11:08 AM

#

Yeah, I get it, that’s frustrating.

Yes, real people do read this, but if this is a real allowlist bug, the most reliable way to get maintainer attention is a GitHub issue:
https://github.com/openclaw/openclaw/issues

If you want, I can help you make that painless. Paste these 3 outputs here:

openclaw --version
openclaw config get channels.whatsapp --json
openclaw config get channels.whatsapp.accounts --json

And this test result:

#

openclaw message send --channel whatsapp --target +90... --message "test"

Then I’ll turn it into a ready-to-paste bug report for you.

Copy/paste issue template

Title
WhatsApp allowFrom rejects newly added numbers after gateway restart

Body

## Summary
WhatsApp outbound works for already-allowed numbers, but newly added numbers still fail with:
`Target "<number>" is not listed in the configured WhatsApp allowFrom policy.`

#


## Environment
- OpenClaw version: <paste output of `openclaw --version`>
- Install method: Homebrew
- OS: macOS M1
- Channel: WhatsApp (Baileys)
- Agent: Nina

## What I changed
I added a new number to `channels.whatsapp.allowFrom` in `~/.openclaw/openclaw.json`
and restarted the gateway.

## Expected
After gateway restart, the newly added number should be accepted.

#

## Actual
OpenClaw still rejects the new number with:
`Target "<number>" is not listed in the configured WhatsApp allowFrom policy.`

## Notes
- Sending works for numbers that were already on the allowlist.
- The issue only affects newly added numbers.
- Restarting the gateway did not fix it.

## Config output
```json
<paste redacted output of `openclaw config get channels.whatsapp --json`>

Accounts output

#


## Repro command
```bash
openclaw message send --channel whatsapp --target +90... --message "test"

Exact CLI output

<paste exact error output>


If this fixed the thread for you, please **right-click the solution message → Apps → ✅ Mark Solution** so Answer Overflow can index it.

floral flax Apr 20, 2026, 11:12 AM

#

tamam bana adım adım nerminali açıp ne yazacağın ne düzelteceğim anlat, mümkünse bana phyton kodları ver yanlış yapma riski minimuma insin

plush lavaBOT Apr 20, 2026, 11:13 AM

#

Tamam. Python verme gerekmiyor, çünkü en güvenlisi OpenClaw’ın kendi config komutları. Böylece yanlış JSON düzenleme riski azalır.

Aşağıyı adım adım yap.

1. Terminal’i aç

İlk olarak versiyonu ve aktif config’i görelim:

openclaw --version
openclaw config file
openclaw config get channels.whatsapp --json
openclaw config get channels.whatsapp.accounts --json

2. Yedek al

Bu güvenli olsun diye:

#

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.backup

3. En risksiz teşhis testi

Amacımız önce sistemi tamamen açıp hatanın gerçekten allowlist’ten mi geldiğini görmek.

Eğer `channels.whatsapp.accounts` boşsa veya `null` ise

Şunları yaz:

openclaw config set channels.whatsapp.dmPolicy '"open"' --strict-json
openclaw config set channels.whatsapp.allowFrom '["*"]' --strict-json

Eğer `channels.whatsapp.accounts` doluysa

Büyük ihtimalle default account kullanıyorsun. Önce bunu dene:

#

openclaw config set channels.whatsapp.accounts.default.dmPolicy '"open"' --strict-json
openclaw config set channels.whatsapp.accounts.default.allowFrom '["*"]' --strict-json

Eğer account adı default değilse, default yerine kendi account id’ni yaz.

4. Kontrol et

Şimdi gerçekten yazılmış mı bak:

Single account için

openclaw config get channels.whatsapp --json

Multi-account için

#

openclaw config get channels.whatsapp.accounts.default --json

Burada dmPolicy: "open" ve allowFrom: ["*"] görmelisin.

5. Gateway’i yeniden başlat

openclaw gateway stop
openclaw gateway start

6. Test mesajı gönder

openclaw message send --channel whatsapp --target +90XXXXXXXXXX --message "test"

#

7. Sonucu yorumla

Eğer bu çalışırsa

Harika. Demek ki:

cache bug değil
config okunuyor
sorun eski allowlist / yanlış account / override

O zaman bir sonraki adımda allowlist’i tekrar güvenli şekilde daraltırız.

Eğer hâlâ `target not listed` diyorsa

O zaman çok büyük ihtimalle:

yanlış account’a yazıyorsun
başka bir config override ediyor
runtime farklı config kullanıyor

Bu durumda bana şu 4 çıktıyı aynen yapıştır:

#

openclaw --version
openclaw config get channels.whatsapp --json
openclaw config get channels.whatsapp.accounts --json
openclaw message send --channel whatsapp --target +90XXXXXXXXXX --message "test"

En kısa özet

Önce bunu dene:

openclaw config set channels.whatsapp.dmPolicy '"open"' --strict-json
openclaw config set channels.whatsapp.allowFrom '["*"]' --strict-json
openclaw gateway stop
openclaw gateway start
openclaw message send --channel whatsapp --target +90XXXXXXXXXX --message "test"

#

Eğer multi-account kullanıyorsan channels.whatsapp yerine channels.whatsapp.accounts.default yolunu kullan.

İstersen bunu yaptıktan sonra çıkan sonucu buraya yapıştır, bir sonraki komutu tek tek ben söyleyeyim.

floral flax Apr 20, 2026, 11:34 AM

#

someone told me to create a support ticket on a link but the message dissappeared

plush lavaBOT Apr 20, 2026, 11:34 AM

#

Ignore it. That was not an official OpenClaw support link.

The official path is:

help here in this thread
if it looks like a real bug, GitHub issues only: https://github.com/openclaw/openclaw/issues

So, good that it disappeared. I would not use that ticket link.

If you want, continue with the step-by-step terminal test I gave above, or paste these outputs and I’ll help you from there:

openclaw --version
openclaw config get channels.whatsapp --json
openclaw config get channels.whatsapp.accounts --json

untold quiverBOT Apr 20, 2026, 11:53 AM

#

floral flax Apr 20, 2026, 12:12 PM

#

please summary the issue and I will continue on another thread,

plush lavaBOT Apr 20, 2026, 12:12 PM

#

Sure, here’s a clean summary you can paste into a new thread:

## WhatsApp issue summary

### Original problem
I had a custom plugin at `~/.openclaw/extensions/whatsapp-tools/` and my agent was hallucinating “message sent” without actually calling a tool.

### What we found
1. **WhatsApp itself is working**
   - `openclaw message send --channel whatsapp --target ... --message ...` works.

2. **The first real issue was tool availability**
   - My agent did **not** have the built-in `message` tool available.
   - Fix was to change the agent tool profile so the agent can use messaging tools.
   - After that, the agent could send successfully.

#


3. **Custom plugin is probably not needed**
   - Recommended path is to use the built-in `message` tool instead of a custom WhatsApp send plugin.

### Current problem
Now the remaining issue is **new numbers**.

- Already-allowed numbers work.
- Newly added numbers fail with:
  `Target "<number>" is not listed in the configured WhatsApp allowFrom policy.`

### What was already tried
- updated `channels.whatsapp.allowFrom`
- restarted gateway
- still seeing the same rejection for newly added numbers

#


### Current suspicion
This may be one of:
1. wrong config scope
2. multi-account override (`channels.whatsapp.accounts.<id>.allowFrom`)
3. duplicate / overridden `channels.whatsapp` config block
4. runtime not using the config block being edited

### Suggested next debug outputs
```bash
openclaw --version
openclaw config get channels.whatsapp --json
openclaw config get channels.whatsapp.accounts --json
openclaw message send --channel whatsapp --target +90... --message "test"

#


### Important note
A random “support ticket” link was posted in-thread earlier, but it was **not** an official OpenClaw support path and should be ignored.

### Official escalation path
If this turns out to be a real bug, use GitHub issues:
https://github.com/openclaw/openclaw/issues

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

floral flax Apr 20, 2026, 1:42 PM

#

buraya kadar geldik mesaj gönderiyor ama yeni numaralaara gönderemiyor, önceden kayıtlı olan 2 numaraya göndermeyi başardı

plush lavaBOT Apr 20, 2026, 1:42 PM

#

Güzel, bu aslında çok önemli bir ilerleme. 🎉

Bu şu anlama geliyor:

mesaj gönderme yolu çalışıyor
agent/tool problemi çözüldü
sorun artık sadece yeni numaralar için allowFrom / active account config

Yani artık problem WhatsApp send değil, effective allowlist.

En olası sebep

Yeni numarayı yanlış scope’a ekliyorsun:

ya channels.whatsapp.allowFrom
ya da aslında aktif olan yer:
channels.whatsapp.accounts.<accountId>.allowFrom

#

Eski 2 numaranın çalışması da bunu destekliyor. Runtime allowlist okuyor, ama yeni eklenen entry doğru active block’a gitmiyor olabilir.

Şimdi sadece bunları gönder

Lütfen şu 2 çıktıyı, numaraları gizleyerek, buraya yapıştır:

openclaw config get channels.whatsapp --json
openclaw config get channels.whatsapp.accounts --json

Ben neye bakacağım

Ben bunlarda şunu kontrol edeceğim:

multi-account var mı
default veya başka account override ediyor mu
yeni numara gerçekten active allowFrom içinde mi
duplicate / override edilmiş block var mı

#Whatsapp Message Failure

What is actually fixing the bug

What plugins.allow would do

If you want the agent to send WhatsApp messages

If you want plugin code to send via WhatsApp programmatically

Best current pattern

What I would avoid

Practical recommendation

Step 1, restart after any plugin code change

Step 2, watch logs live during one test

Step 3, turn on tool visibility in the agent chat

Step 4, test the built-in path first

Result interpretation

Step 5, test your custom tool directly

Result interpretation

Step 6, if the custom tool is called but still fails

Step 7, if no custom tool call happens at all

Step 8, what to paste back here

Do this next, in this exact order

1. Test proactive send without the agent

2. Watch the result carefully

If it fails with something like:

3. If the CLI proactive send works

Result:

4. If built-in message tool works

My best guess right now

What to do now

Fastest fix

If that works

If Nina still replies normally and does not call the tool

My recommendation

Good news

Simple next steps

Step 1

Step 2

Step 3

What should happen

If it works

If it does NOT work

Important

Most likely causes

Keep it simple, do these 3 steps

Step 1

Step 2

Step 3

Important

Best setup I recommend

1. Use the built-in WhatsApp path, not your custom plugin

2. Keep proactive sending separate from normal chat replying

Send an exact message to a person/group

Ask the agent to generate and deliver a proactive message

3. Use a separate admin chat for yourself

4. Keep transcripts on disk

5. Use a stronger model if reliability matters

My recommendation for your goals

3 questions for you

1. Put this in Nina’s instructions / system prompt

2. Then send Nina this exact prompt when you want a message sent

3. Even stronger version

Important

Root cause

Best simple fix

If Nina is mainly for WhatsApp / chat / bridge use

If you want Nina to have everything

Where to change it

Important

Then do this

My recommendation

What controls new numbers

Easiest choices

Option A, easiest, any new number works

Option B, safer, manual whitelist

Option C, middle ground

My recommendation for your use case

Important note

Quick fix

Allow only one number

Allow any number

Basic troubleshooting prompt for Nina

Even simpler

What `plugins.allow` would do

Eğer yine `target not listed` diyorsa

Eğer `channels.whatsapp.accounts` boşsa veya `null` ise

Eğer `channels.whatsapp.accounts` doluysa

Eğer hâlâ `target not listed` diyorsa