Blocked: Agent Communication Failure in OpenClaw with Gemini CLI | Friends of the Crustacean 🦞🤝 | Page 1

pliant cloak Apr 27, 2026, 7:06 PM

#

My agent, Rindhani, is unable to delegate tasks to other agents (Ilza, Nabil) as required. This is due to a combination of a missing primary tool, conflicting instructions for the suggested alternative, and a critical authentication failure.

Details:

Missing sessions_send Tool:
• My core instructions (AGENTS.md) mandate using the sessions_send tool for direct, one-to-one agent task delegation.
• This tool is not available in my current environment, resulting in a "Tool not found" error. This is the primary blocker.
Instruction Conflict with openclaw.invoke:
• The suggested workaround is to use openclaw.invoke --tool message.
• However, my investigation shows this tool sends a message to the group Telegram channel
• My instructions explicitly forbid using group chat for delegation: "Delegate via sessions_send (NOT by posting in group chat)". This creates a direct operational conflict.
Authentication Failure for openclaw.invoke:
• All attempts to use the openclaw.invoke command fail with an "Unauthorized" error.
• Analysis of the lobster workflow tool and its test files confirms that openclaw.invoke requires an OPENCLAW_TOKEN environment variable for authentication against the OpenClaw backend.

shut canopyBOT Apr 27, 2026, 7:06 PM

#

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

jaunty kindleBOT Apr 27, 2026, 7:09 PM

#

Please paste openclaw --version first — version matters a lot here.

That said, the likely issue is tool policy, not that sessions_send doesn’t exist globally.

Key points:

Don’t use openclaw.invoke --tool message for this.
If Rindhani’s instructions forbid group-chat delegation, message is the wrong workaround.
sessions_send can be filtered out.
It is controlled by tool profile/policy. Check from the same Rindhani session:
```
/tools
```
Docs: https://docs.openclaw.ai/concepts/session-tool

#

For cross-agent sessions_send, you likely need both session visibility and agent-to-agent enabled:

{
  tools: {
    profile: "coding",
    sessions: { visibility: "all" },
    agentToAgent: {
      enabled: true,
      allow: ["rindhani", "ilza", "nabil"]
    }
  }
}

If Rindhani is itself a sub-agent/ACP child, sessions_send may be intentionally absent. Sub-agents normally report upward through the announce chain, not direct-send to peers. Prefer parent orchestration with sessions_spawn targeting agentId: "ilza" / "nabil".

#

Auth note: Gateway HTTP tool invoke uses OPENCLAW_GATEWAY_TOKEN or OPENCLAW_GATEWAY_PASSWORD, not plain OPENCLAW_TOKEN. Also, sessions_send is on the default HTTP /tools/invoke denylist, so using invoke for this is not the normal path anyway.

Please share:

openclaw --version
openclaw status --all

and the /tools output from Rindhani. Don’t paste any raw gateway tokens.

pliant cloak Apr 27, 2026, 7:14 PM

#

All my agent tools has a

Profile: full

Built-in tools
agents_list, canvas, cron, edit, exec, gateway, message, nodes, process, read, sessions_history, sessions_send, session_status, sessions_list, sessions_spawn, subagents, tts, web_fetch, web_search, write, sessions_yield

Connected tools
browser (browser), lobster (lobster), memory_get (memory-core), memory_search (memory-core)

jaunty kindleBOT Apr 27, 2026, 7:15 PM

#

That changes the diagnosis: sessions_send is not missing from OpenClaw. Your /tools output proves it’s available in the OpenClaw agent tool surface.

So the “Tool not found” is almost certainly coming from a different execution context:

OpenClaw agent context: has sessions_send.
Gemini CLI / ACP harness context: does not automatically receive OpenClaw built-in tools.
Lobster / openclaw.invoke context: direct HTTP/tool invocation, not native agent delegation.

So if Rindhani is running as Gemini CLI via ACP, then an AGENTS.md instruction saying “call sessions_send” is incompatible unless OpenClaw is the caller. ACP harnesses don’t get built-in OpenClaw tools by default, and the OpenClaw-tools MCP bridge currently only exposes selected core tools, not general sessions_send.

Recommended fix:

Do not use openclaw.invoke --tool message for this. That’s channel messaging, not private agent delegation.
If Rindhani must directly delegate with sessions_send, run Rindhani as a native OpenClaw agent/session, not as Gemini CLI ACP.
If Rindhani stays as Gemini CLI ACP, move delegation up one layer: have the parent OpenClaw agent call sessions_send / sessions_spawn to Ilza and Nabil.

Docs:

#

Also please still paste openclaw --version and the exact place the “Tool not found” appears — Gemini output vs OpenClaw tool result vs Lobster output. That will confirm which context is throwing it.

pliant cloak Apr 27, 2026, 7:21 PM

#

openclaw --version
OpenClaw 2026.4.24 (cbcfdf6)

Oh, I haven’t set up ACP yet? How do I fix that?

jaunty kindleBOT Apr 27, 2026, 7:22 PM

#

Yep — but one important caveat: ACP won’t make Gemini CLI magically have sessions_send inside Gemini. ACP lets OpenClaw run Gemini CLI as an external harness. Delegation to Ilza/Nabil should still be done by the OpenClaw parent agent using sessions_spawn / sessions_send.

To enable Gemini ACP:

openclaw config set --batch-json '[
  {"path":"acp.enabled","value":true},
  {"path":"acp.backend","value":"acpx"},
  {"path":"acp.defaultAgent","value":"gemini"},
  {"path":"acp.allowedAgents","value":["gemini"]},
  {"path":"channels.discord.threadBindings.enabled","value":true},
  {"path":"channels.discord.threadBindings.spawnAcpSessions","value":true}
]'
openclaw gateway restart

Then in chat:

#

/acp doctor

If doctor passes, try:

/acp spawn gemini --mode persistent --thread auto

Also verify Gemini CLI auth works on the same machine/user running the Gateway. ACP launches the real Gemini harness process, so Gemini’s own login/API-key setup has to be working separately.

Docs:

And don’t worry about OPENCLAW_TOKEN for this path — for OpenClaw Gateway auth it’s OPENCLAW_GATEWAY_TOKEN / password, but you shouldn’t need openclaw.invoke --tool message for this delegation flow.

pliant cloak Apr 27, 2026, 7:27 PM

#

Does that mean I need to set up a new agent for the OpenClaw parent agent? So I can’t use the full agent with the Gemini CLI?

jaunty kindleBOT Apr 27, 2026, 7:28 PM

#

No — you don’t necessarily need a new parent agent.

You can use your existing “full” OpenClaw agent as the parent/orchestrator. The key distinction is:

OpenClaw agent with profile: full → has sessions_send, sessions_spawn, etc.
Gemini CLI via ACP → external harness; it does not become a full OpenClaw tool-using agent internally.

So the recommended setup is:

Rindhani = normal OpenClaw agent / orchestrator / full tools
  ├─ uses sessions_send or sessions_spawn to Ilza
  ├─ uses sessions_send or sessions_spawn to Nabil
  └─ can spawn Gemini CLI via ACP for coding work

What you probably don’t want is:

#

Rindhani = Gemini CLI ACP runtime

because then Rindhani’s own AGENTS.md telling it “call sessions_send” won’t work inside Gemini.

So: keep Rindhani as the OpenClaw parent, and let it call Gemini as a child/tool runtime when needed. If you currently configured Rindhani with something like runtime.type: "acp", remove that from Rindhani and instead use ACP only when spawning Gemini tasks.

pliant cloak Apr 27, 2026, 7:34 PM

#

How to keep Rindhani as the openclaw parent?

jaunty kindleBOT Apr 27, 2026, 7:35 PM

#

To keep Rindhani as the OpenClaw parent, make Rindhani a normal OpenClaw agent, not an ACP-bound Gemini session.

Check your config:

openclaw config get agents.list --json

Find the Rindhani entry. It should not have this:

runtime: {
  type: "acp",
  acp: { agent: "gemini" }
}

#

If it does, remove that runtime block from Rindhani. Rindhani should look conceptually like:

{
  id: "rindhani",
  tools: { profile: "full" },
  subagents: { allowAgents: ["ilza", "nabil", "gemini"] }
}

Then Rindhani can delegate like this:

to Ilza/Nabil: normal OpenClaw delegation via sessions_send / sessions_spawn
to Gemini CLI: only when needed, via sessions_spawn({ runtime: "acp", agentId: "gemini", ... })

So yes: you can keep the full OpenClaw agent. Just don’t make that agent itself be the Gemini ACP harness.

#

Important nuance: using Gemini as a model/provider is different from using Gemini CLI ACP as the runtime. The second one is what loses native OpenClaw tools like sessions_send.

Docs:
https://docs.openclaw.ai/gateway/config-agents
https://docs.openclaw.ai/concepts/session-tool
https://docs.openclaw.ai/tools/acp-agents

pliant cloak Apr 27, 2026, 7:44 PM

#

thats my problem i'm using Gemini as a model/provider not as ACP

jaunty kindleBOT Apr 27, 2026, 7:44 PM

#

Ah — then ignore the ACP setup path. If Rindhani is using Gemini only as the model/provider, Rindhani is still the OpenClaw parent.

Since /tools shows sessions_send, the issue is no longer “missing tool”. It’s one of these:

Gemini is failing to call the tool correctly
If the model says “Tool not found” in normal text, that’s likely model/tool-call confusion, not OpenClaw policy.
Wrong delegation primitive
sessions_send sends to an existing session. If Ilza/Nabil don’t already have visible sessions/labels, use sessions_spawn with agentId: "ilza" / "nabil" instead.
Cross-agent visibility missing
If sending to existing Ilza/Nabil sessions, set:

{
  tools: {

#

    sessions: { visibility: "all" },
    agentToAgent: {
      enabled: true,
      allow: ["rindhani", "ilza", "nabil"]
    }
  }
}

For task delegation, I’d make Rindhani’s instruction say:

Use sessions_spawn for new tasks to Ilza/Nabil. Use sessions_send only for follow-ups to an existing visible session.

Then restart:

#Blocked: Agent Communication Failure in OpenClaw with Gemini CLI