Problem

When tools.sessions.visibility is set to tree (the default) and tools.agentToAgent.enabled=true with appropriate allow patterns, sessions_send is still blocked for cross-agent messaging. The visibility guard in createSessionVisibilityGuard rejects all cross-agent access when visibility !== "all", regardless of the a2a policy.

This forces operators into an all-or-nothing choice:

• visibility=all → send works, but list/history also exposes cross-agent sessions (data leak risk)
• visibility=tree → data isolation preserved, but send is blocked despite a2a policy allowing it

Use Case

Multi-agent deployments where:

• Each agent runs in a sandbox with sessionToolsVisibility=spawned
• Agents need to send messages to each other (sidecar → platform, partner → coordinator)
• Agents must not list or read each other's session history

This is the standard model for platforms hosting multiple tenant agents on a single OpenClaw instance, where a2a policy defines the trust boundary for messaging.

Root Cause

createSessionVisibilityGuard (sessions-access.ts) applies the same visibility check to all actions:

if (isCrossAgent) {
  if (params.visibility !== "all") {  // ← blocks send even when a2a allows it
    return { allowed: false, status: "forbidden", ... };
  }
  // a2a policy check comes after — never reached
}

Additionally, restrictToSpawned in sessions-send-tool.ts adds spawnedBy to label resolution, which prevents resolving cross-agent session targets entirely.

Proposal

Let the a2a policy serve as the authorization gate for sessions_send, independent of the visibility setting that governs list/history/status.

Conceptually:

This could be implemented as:

1. Per-action visibility exception: skip the visibility gate for send when a2a policy explicitly allows the target agent, or
2. New visibility level: e.g. tree+a2a-send that preserves tree isolation for read operations but allows a2a-gated sends, or
3. Separate config key: tools.sessions.sendVisibility that defaults to a2a while keeping the existing visibility for other actions

Option 1 is the simplest and aligns with the existing a2a policy design — the policy already validates requester→target agent pairs, so it provides equivalent or stronger authorization than visibility alone.

Security Analysis

With option 1 (a2a policy gates send):

No new attack surface is introduced — send already requires a2a policy approval, which is a stricter check than visibility=all (which allows everything).

Related

• GHSA-6hf3-mhgc-cm65 — session visibility hardening (introduced the current behavior)
• Platform prerequisites for multi-agent per-org isolation #10004 — multi-agent isolation prerequisites (acknowledges sessions_send is denied as interim mitigation)
• Cross-AI IPC: let OpenClaw sessions talk to Claude Code, Codex, and external tools #55872 — cross-AI IPC feature request

Environment

• OpenClaw v2026.3.24+ (tree visibility default)
• Multi-agent deployment with sandbox, a2a enabled