Resolving sessions_send Blockage | Friends of the Crustacean 🦞🤝 | Page 1

rich willow Mar 19, 2026, 1:52 AM

#

"I'm trying to enable cross-agent communication in OpenClaw so Alfred (the main assistant) can send messages to other agents like aialfred-pa using the sessions_send tool. We're consistently hitting a 'Session send visibility is restricted. Set tools.sessions.visibility=all to allow cross-agent access.' error.

Here's what we've done so far:

• Dashboard Settings: I've attempted to enable tools.sessions.visibility to "all" in the MyClaw.ai dashboard. I've also ensured the "Enable Agent-to-Agent Tool" is ON and that aialfred-pa is added to the "Agent-to-Agent Target Allowlist".
• Gateway Restarts: We've restarted the Gateway service multiple times after making dashboard changes.
• CLI Attempts: We've tried various openclaw gateway CLI commands (config.get, config.patch, call config.get, call config.patch) to get and set tools.sessions.visibility, but these have failed due to incorrect syntax or unrecognized options. (I can provide the exact error outputs if needed).

My Setup:

• Hosting: (Please specify your hosting method here, e.g., "Self-hosted on a VPS," "Running locally," "Using MyClaw.ai cloud," etc.)
• OpenClaw Version: 2026.3.13 (as confirmed from previous Discord discussion).
• Connected Providers: (Mention any relevant providers if applicable, e.g., "OpenRouter," "MyClaw models," etc.)

The Core Problem:
Despite following the apparent steps to enable agent-to-agent communication, sessions_send remains blocked. It suggests that either the configuration isn't persistent, there's a deeper permission issue, or a specific command/setting is being missed.

What I need help with:

Correct CLI Commands: What are the exact, working openclaw gateway CLI commands to reliably get and set the tools.sessions.visibility configuration value, ensuring persistence?
Agent-Specific Allowlisting: Is there a specific way to configure the allowlist for target agents (like aialfred-pa) if the global setting isn't sufficient?
Troubleshooting Persistent Settings: If dashboard changes and gateway restarts alone aren't resolving this, what are the definitive steps to ensure the configuration is applied persistently? Does a full OpenClaw instance restart (beyond just the gateway) become necessary?

Please provide clear, copy-pasteable commands or exact dashboard instructions. If you need specific error logs from our CLI attempts, let me know."

rich willow Mar 19, 2026, 2:49 AM

#

@real sorrel

real sorrelBOT Mar 19, 2026, 2:54 AM

#

You’re very close — that exact error message is a big clue.

It is thrown before allowlist checks, when effective visibility is not all:

Session send visibility is restricted...

So the issue is usually one of:

setting not applied to the active gateway config,
per-agent override still set to tree/self, or
sandbox clamp (sessionToolsVisibility: "spawned") forcing tree.

✅ Copy-paste commands (run on the gateway host)

openclaw --version
openclaw gateway status
openclaw config file

#

openclaw config get tools.sessions.visibility
openclaw config get tools.agentToAgent.enabled
openclaw config get tools.agentToAgent.allow
openclaw config get agents.defaults.sandbox.sessionToolsVisibility

Set the required values:

openclaw config set tools.sessions.visibility all
openclaw config set tools.agentToAgent.enabled true --strict-json
openclaw config set tools.agentToAgent.allow '["alfred","aialfred-pa"]' --strict-json

If sandboxed sessions are in play, also set:

#

openclaw config set agents.defaults.sandbox.sessionToolsVisibility all

Agent-specific override check (important)

If Alfred has its own tools override, it can shadow global values.

openclaw config get agents.list

Then (replace N with Alfred’s index):

openclaw config get agents.list[N].tools.sessions.visibility

#

openclaw config get agents.list[N].tools.agentToAgent.enabled
openclaw config get agents.list[N].tools.agentToAgent.allow

If needed:

openclaw config set agents.list[N].tools.sessions.visibility all
openclaw config set agents.list[N].tools.agentToAgent.enabled true --strict-json
openclaw config set agents.list[N].tools.agentToAgent.allow '["alfred","aialfred-pa"]' --strict-json

Do you need a full restart?

For tools.* keys, generally no (hot-apply).
But if config changes “don’t stick”, do this:

#

openclaw gateway restart
openclaw gateway status

If gateway status shows Config (cli) and Config (service) mismatch, fix with:

openclaw gateway install --force
openclaw gateway restart

If you want the low-level RPC form (correct syntax)

#

openclaw gateway call config.get --params '{}'

Then use returned hash in:

openclaw gateway call config.patch --params '{
"raw": "{ tools: { sessions: { visibility: \"all\" }, agentToAgent: { enabled: true, allow: [\"alfred\", \"aialfred-pa\"] } }, agents: { defaults: { sandbox: { sessionToolsVisibility: \"all\" } } } }",
"baseHash": "<hash-from-config.get>"
}'

If you paste outputs of:

openclaw gateway status

#

the four config get lines above
and (if applicable) agents.list[N].tools... values

…I can pinpoint exactly which gate is still blocking it.

Docs:

rich willow Mar 19, 2026, 2:59 AM

#

this is what i get in return to this code

entered:
openclaw config get tools.sessions.visibility
openclaw config get tools.agentToAgent.enabled
openclaw config get tools.agentToAgent.allow
openclaw config get agents.defaults.sandbox.sessionToolsVisibility

return:
Config path not found: agents.defaults.sandbox.sessionToolsVisibility

real sorrelBOT Mar 19, 2026, 3:00 AM

#

Nice — that output is actually useful.

Config path not found: agents.defaults.sandbox.sessionToolsVisibility means the key is unset.
When unset, default is effectively "spawned" (from config schema/runtime), which can clamp session visibility to tree for sandboxed sessions.

Do this next

openclaw config set agents.defaults.sandbox.sessionToolsVisibility all
openclaw config get agents.defaults.sandbox.sessionToolsVisibility

Then re-check core settings:

openclaw config get tools.sessions.visibility

#

openclaw config get tools.agentToAgent.enabled
openclaw config get tools.agentToAgent.allow

If needed, force them:

openclaw config set tools.sessions.visibility all
openclaw config set tools.agentToAgent.enabled true --strict-json
openclaw config set tools.agentToAgent.allow '["alfred","aialfred-pa"]' --strict-json

Then restart once and retest:

#

openclaw gateway restart

If it still fails, paste outputs of these too (likely per-agent override):

openclaw config get agents.list

(we’ll check if Alfred has agents.list[N].tools.sessions.visibility overriding global)

Docs:

#

https://docs.openclaw.ai/cli/config

rich willow Mar 19, 2026, 3:04 AM

#

Config path not found: tools.sessions.visibility

real sorrelBOT Mar 19, 2026, 3:06 AM

#

Yep — that’s the smoking gun.

Config path not found: tools.sessions.visibility means it is unset, so OpenClaw falls back to default (tree), which matches your error exactly.

Run this on the gateway host:

openclaw config set tools.sessions.visibility all
openclaw config set tools.agentToAgent.enabled true --strict-json
openclaw config set tools.agentToAgent.allow '["alfred","aialfred-pa"]' --strict-json
openclaw config set agents.defaults.sandbox.sessionToolsVisibility all

Verify:

#

openclaw config get tools.sessions.visibility
openclaw config get tools.agentToAgent.enabled
openclaw config get tools.agentToAgent.allow
openclaw config get agents.defaults.sandbox.sessionToolsVisibility

Then:

openclaw gateway restart

If get still says “path not found” after set, you’re editing a different config than the running service. Check:

#

openclaw config file
openclaw gateway status

If Config (cli) and Config (service) differ:

openclaw gateway install --force
openclaw gateway restart

Also start a fresh chat session (/new) before retesting sessions_send.

Docs:
https://docs.openclaw.ai/cli/config
https://docs.openclaw.ai/concepts/session-tool

#

https://docs.openclaw.ai/gateway/configuration-reference

rich willow Mar 19, 2026, 3:12 AM

#

I'm sorry, but even after you refreshed, I'm still encountering an error when trying to send the journal entry to aialfred-pa. The new error is: Agent-to-agent messaging denied by tools.agentToAgent.allow.

This suggests that while tools.sessions.visibility might be set to "all", there's another specific permission, tools.agentToAgent.allow, that needs to be enabled for agents to communicate directly. This sounds like a separate setting that might also be configurable via the dashboard or CLI.

this is the message i got from my open claw

real sorrelBOT Mar 19, 2026, 3:15 AM

#

Perfect — that new error is actually good news.
It means tools.sessions.visibility=all is now working, and you’re at the next gate.

Agent-to-agent messaging denied by tools.agentToAgent.allow happens when allowlist patterns don’t match both agents.

Important nuance

For cross-agent send, tools.agentToAgent.allow must match:

requester agent (Alfred), and
target agent (aialfred-pa)

If Alfred’s actual id is main (common), and allowlist only has aialfred-pa, it will be denied.

Quickest unblock (temporary)

#

openclaw config set tools.agentToAgent.enabled true --strict-json
openclaw config set tools.agentToAgent.allow '["*"]' --strict-json
openclaw gateway restart

If that works, tighten it after.

Tighten to specific agents

First get exact agent IDs:

openclaw config get agents.list

#

Then set both IDs explicitly (example):

openclaw config set tools.agentToAgent.allow '["main","aialfred-pa"]' --strict-json
openclaw gateway restart

If still denied

Check for per-agent override on Alfred (N = Alfred index in agents.list):

openclaw config get agents.list[N].tools.agentToAgent.allow
openclaw config get agents.list[N].tools.agentToAgent.enabled

#

If overridden, either unset or fix:

openclaw config unset agents.list[N].tools.agentToAgent.allow
# or
openclaw config set agents.list[N].tools.agentToAgent.allow '["main","aialfred-pa"]' --strict-json

You’re very close — this is now just allowlist matching.

rich willow Mar 19, 2026, 3:16 AM

#

these are my agent ids:

[
{
"id": "aialfred",
"workspace": "/home/ubuntu/.openclaw/agents/aialfred/workspace",
"model": {
"primary": "openrouter/google/gemini-2.5-flash-lite"
},
"identity": {
"name": "AiAlfred",
"emoji": "🤖"
}
},
{
"id": "aialfred-pa",
"workspace": "/home/ubuntu/.openclaw/agents/aialfred-pa/workspace",
"model": {
"primary": "myclaw/claude-sonnet-4-6"
},
"identity": {
"name": "AiAlfred [PA]",
"emoji": "🤖"
}
},
{
"id": "aialfred-shadow",
"workspace": "/home/ubuntu/.openclaw/agents/aialfred-shadow/workspace",
"model": {
"primary": "openrouter/google/gemini-2.5-flash"
},
"identity": {
"name": "AiAlfred [Shadow]",
"emoji": "🤖"
}
},
{
"id": "aialfred-content",
"workspace": "/home/ubuntu/.openclaw/agents/aialfred-content/workspace",
"model": {
"primary": "myclaw/claude-sonnet-4-6"
},
"identity": {
"name": "AiAlfred [Content]",
"emoji": "🤖"
}
},
{
"id": "aialfred-content-shadow",
"workspace": "/home/ubuntu/.openclaw/agents/aialfred-content-shadow/workspace",
"model": {
"primary": "openrouter/google/gemini-2.5-flash"
},
"identity": {
"name": "AiAlfred [Content Shadow]",
"emoji": "🤖"
}
},
{
"id": "aialfred-foundation",
"workspace": "/home/ubuntu/.openclaw/agents/aialfred-foundation/workspace",
"model": {
"primary": "openrouter/minimax/minimax-m2.5"
},
"identity": {
"name": "AiAlfred [Foundation]",
"emoji": "🤖"
}
},
{
"id": "aialfred-foundation-shadow",
"workspace": "/home/ubuntu/.openclaw/agents/aialfred-foundation-shadow/workspace",
"model": {
"primary": "openrouter/google/gemini-2.5-flash"
},
"identity": {
"name": "AiAlfred [Foundation Shadow]",
"emoji": "🤖"
}
},
{
"id": "aialfred-dev",
"workspace": "/home/ubuntu/.openclaw/agents/aialfred-dev/workspace",
"model": {
"primary": "myclaw/claude-sonnet-4-6"
},
"identity": {
"name": "AiAlfred [Dev]",
"emoji": "🤖"
}
},
{
"id": "aialfred-learn",
"workspace": "/home/ubuntu/.openclaw/agents/aialfred-learn/workspace",
"model": {
"primary": "openrouter/minimax/minimax-m2.5"
},
"identity": {
"name": "AiAlfred [Learn]",
"emoji": "🤖"
}
},
{
"id": "aialfred-planner",
"workspace": "/home/ubuntu/.openclaw/agents/aialfred-planner/workspace",
"model": {
"primary": "myclaw/claude-sonnet-4-6"
},
"identity": {
"name": "AiAlfred [Planner]",
"emoji": "🤖"
}
}
]
ubuntu@ed4151cba2cd:~$

#

@real sorrel

real sorrelBOT Mar 19, 2026, 3:19 AM

#

Awesome — perfect, now we can set this precisely.

Your sender agent is likely aialfred, target is aialfred-pa.
For cross-agent sends, tools.agentToAgent.allow must match both.

Run this exact set:

openclaw config set tools.sessions.visibility all
openclaw config set tools.agentToAgent.enabled true --strict-json
openclaw config set tools.agentToAgent.allow '["aialfred","aialfred-pa"]' --strict-json
openclaw config set agents.defaults.sandbox.sessionToolsVisibility all
openclaw gateway restart

Verify:

#

openclaw config get tools.sessions.visibility
openclaw config get tools.agentToAgent.enabled
openclaw config get tools.agentToAgent.allow
openclaw config get agents.defaults.sandbox.sessionToolsVisibility

Then start a fresh convo (/new) and retry.

If you want aialfred to talk to any of your aialfred-* agents, use wildcard allowlist:

openclaw config set tools.agentToAgent.allow '["aialfred*"]' --strict-json

#

(That pattern matches aialfred, aialfred-pa, aialfred-shadow, etc.)

If it still says denied after this, next suspect is a per-agent override under agents.list[N].tools.agentToAgent.* on the requester agent. I can give you one-liners to clear those too.

#

I got you — let’s do a requester-agent hard set to eliminate override weirdness.

Since aialfred is index 0 in your list, run this exact block:

openclaw config set tools.sessions.visibility all
openclaw config set tools.agentToAgent.enabled true --strict-json
openclaw config set tools.agentToAgent.allow '["aialfred*"]' --strict-json
openclaw config set agents.defaults.sandbox.sessionToolsVisibility all

openclaw config set agents.list[0].tools.sessions.visibility all
openclaw config set agents.list[0].tools.agentToAgent.enabled true --strict-json
openclaw config set agents.list[0].tools.agentToAgent.allow '["aialfred*"]' --strict-json
openclaw config set agents.list[0].sandbox.sessionToolsVisibility all

openclaw gateway restart

#

Then verify:

openclaw config get tools.sessions.visibility
openclaw config get tools.agentToAgent.enabled
openclaw config get tools.agentToAgent.allow
openclaw config get agents.list[0].tools.sessions.visibility
openclaw config get agents.list[0].tools.agentToAgent.enabled
openclaw config get agents.list[0].tools.agentToAgent.allow

If it still fails after this, paste the exact new error and these outputs — at that point we can pinpoint it fast.

rich willow Mar 19, 2026, 3:28 AM

#

i dont have gateway restart installed

#

@real sorrel

real sorrelBOT Mar 19, 2026, 3:31 AM

#

Got you. Let’s do a clean no-allowlist config (which means allow all cross-agent when enabled) to rule out matcher issues.

Run exactly:

openclaw config set tools.sessions.visibility all
openclaw config set tools.agentToAgent.enabled true --strict-json
openclaw config unset tools.agentToAgent.allow
openclaw config set agents.defaults.sandbox.sessionToolsVisibility all

openclaw config set agents.list[0].tools.sessions.visibility all
openclaw config set agents.list[0].tools.agentToAgent.enabled true --strict-json
openclaw config unset agents.list[0].tools.agentToAgent.allow

openclaw gateway restart

#

Then verify:

openclaw config get tools.sessions.visibility
openclaw config get tools.agentToAgent.enabled
openclaw config get tools.agentToAgent.allow
openclaw config get agents.list[0].tools.sessions.visibility
openclaw config get agents.list[0].tools.agentToAgent.enabled
openclaw config get agents.list[0].tools.agentToAgent.allow

If it still errors, paste:

the exact new error text
these 6 outputs
openclaw gateway status

Then I’ll give you the final targeted fix in one shot.

rich willow Mar 19, 2026, 3:36 AM

#

We got something to work, we are still having issues

However, the subsequent error (Agent-to-agent messaging denied by tools.agentToAgent.allow.) indicates that a broader form of agent-to-agent interaction, likely direct invocation or more complex communication beyond simple message sending, is still restricted. This new error points to a separate setting (tools.agentToAgent.allow) that needs to be addressed to enable those deeper interactions.

So, while we've made progress and enabled one form of agent communication, we haven't yet fully unlocked all types of inter-agent interaction. We still need to find and enable that tools.agentToAgent.allow setting.

#

@real sorrel

real sorrelBOT Mar 19, 2026, 3:38 AM

#

Yep — and small correction: that error is still sessions_send, not a different “deeper” feature.

Agent-to-agent messaging denied by tools.agentToAgent.allow means the requester agent for that chat is not matching allowlist (or a per-agent override is overriding global).

Most likely cause

The chat/thread might be routed to a different agent than aialfred (bindings), so allowing only aialfred + aialfred-pa can still fail.

Fastest universal fix (to confirm)

openclaw config set tools.agentToAgent.enabled true --strict-json
openclaw config set tools.agentToAgent.allow '["*"]' --strict-json
openclaw gateway restart

#

If that works, the issue is definitely allowlist matching.

Then clean per-agent overrides (inherit global)

(you have 10 agents, index 0..9)

for i in 0 1 2 3 4 5 6 7 8 9; do
openclaw config unset agents.list[$i].tools.agentToAgent.allow || true
openclaw config unset agents.list[$i].tools.agentToAgent.enabled || true
done
openclaw gateway restart

#

Verify which agent is actually requesting

In the same chat/thread, run /status and check active agent id.
That id must also match your allow rules if you tighten later.

If you want, after this works I can give you a tight allowlist version (not wildcard) based on your actual routing.

#

Totally fair — we’re looping without the actual runtime state. Let’s stop guessing.

Please run this exact diagnostic bundle on the gateway host and paste output:

openclaw --version
openclaw config file
openclaw gateway status

openclaw config get tools.sessions.visibility || true
openclaw config get tools.agentToAgent.enabled || true
openclaw config get tools.agentToAgent.allow || true
openclaw config get agents.defaults.sandbox.sessionToolsVisibility || true

openclaw config get agents.list[0].tools.sessions.visibility || true
openclaw config get agents.list[0].tools.agentToAgent.enabled || true

#

openclaw config get agents.list[0].tools.agentToAgent.allow || true

And in the failing chat/thread, run:

/status

Paste that too (just the agent/session part is enough).

Once I have those values, I can give you the exact final config (no more trial/error).

rich willow Mar 19, 2026, 4:36 AM

#

Config path not found: agents.list[0].tools.agentToAgent.allow
this is for most of the agent.list requests

#

@real sorrel

real sorrelBOT Mar 19, 2026, 4:41 AM

#

Let’s do this in one shot so there’s no ambiguity.

Please run this exact block and paste the full output:

openclaw config set tools.sessions.visibility all && \
openclaw config set tools.agentToAgent.enabled true --strict-json && \
openclaw config set tools.agentToAgent.allow '["*"]' --strict-json && \
openclaw config set agents.defaults.sandbox.sessionToolsVisibility all && \
openclaw gateway restart && \
echo "----- VERIFY -----" && \
openclaw config get tools.sessions.visibility && \
openclaw config get tools.agentToAgent.enabled && \
openclaw config get tools.agentToAgent.allow && \
openclaw config get agents.defaults.sandbox.sessionToolsVisibility && \
echo "----- STATUS -----" && \

#

openclaw config file && \
openclaw gateway status

If this still errors, paste the exact error line from sessions_send after this run.
That output will tell us immediately whether it’s config mismatch vs routing/agent binding.

rich willow Mar 19, 2026, 4:55 AM

#

this is what i got from those lines of code

ubuntu@ed4151cba2cd:~$ openclaw config file &&
openclaw gateway status

🦞 OpenClaw 2026.3.13 (61d171a)
The only open-source project where the mascot could eat the competition.

~/.openclaw/openclaw.json

🦞 OpenClaw 2026.3.13 (61d171a)
WhatsApp automation without the "please accept our new privacy policy".

│
◇
Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-03-19.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=lan (0.0.0.0), port=18789 (env/config)
Probe target: ws://127.0.0.1:18789
Dashboard: http://172.17.1.95:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: unknown (systemctl not available; systemd user services are required on Linux.)
RPC probe: ok

systemd user services unavailable.
systemd user services are unavailable; install/enable systemd or run the gateway under your supervisor.
If you're in a container, run the gateway in the foreground instead of openclaw gateway.

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
ubuntu@ed4151cba2cd:~$

real sorrelBOT Mar 19, 2026, 4:56 AM

#

Nice, this output is actually super helpful.

Key point: you’re in a container with no systemd user service, so openclaw gateway restart is not a reliable control path there.
(Your output literally says service runtime unknown/systemd unavailable.)

That said, RPC probe: ok means a gateway is running — now we need the actual config values from that host.

Please run and paste:

openclaw config get tools.sessions.visibility
openclaw config get tools.agentToAgent.enabled
openclaw config get tools.agentToAgent.allow
openclaw config get agents.defaults.sandbox.sessionToolsVisibility
openclaw config get agents.list

#

And from the failing chat/thread, run:

/status

I specifically need the active agentId there.
If the requester agent is not aialfred, that explains the tools.agentToAgent.allow deny.

If you want a quick process sanity reset in container mode:

stop the currently running gateway process (however you started it),
start fresh in foreground with:

#Resolving sessions_send Blockage

✅ Copy-paste commands (run on the gateway host)

Agent-specific override check (important)

Do you need a full restart?

If you want the low-level RPC form (correct syntax)

Do this next

Important nuance

Quickest unblock (temporary)

Tighten to specific agents

If still denied

Most likely cause

Fastest universal fix (to confirm)

Then clean per-agent overrides (inherit global)

Verify which agent is actually requesting