Summary

After upgrading to 2026.6.1, direct Jarvis -> Billy orchestration attempts were blocked before reaching Billy with:

Session send visibility is restricted. Set tools.sessions.visibility=all to allow cross-agent access.

This is confusing because the local config already allowed Jarvis to delegate to Billy through agents.list[].subagents.allowAgents, and Billy was alive via heartbeat. The failure looked like "Billy is flaky/dead" from the operator side, but the clean direct health-check call was rejected by session visibility policy before it reached Billy.

Environment

• OpenClaw: 2026.6.1 (2e08f0f)
• Previous version before upgrade: 2026.5.18 (50a2481)
• Platform: macOS arm64
• Gateway: LaunchAgent, loopback 127.0.0.1:18789
• Agents: main/Jarvis, billy, farber, scout, maverick, lumbergh
• Jarvis subagent config already included:

"subagents": {
  "allowAgents": ["billy", "farber", "scout", "maverick", "lumbergh"]
}

Observed behavior

Jarvis attempted a direct health-check style call to Billy's main session (agent:billy:main) and OpenClaw rejected it with:

Session send visibility is restricted. Set tools.sessions.visibility=all to allow cross-agent access.

This happened while Billy heartbeat was still alive, so the issue was not that Billy was missing. It was a policy/runtime gate blocking direct cross-agent session access.

A second layer exists in 6.1: the schema says tools.sessions.visibility=all controls cross-session visibility, but cross-agent access also requires tools.agentToAgent.

Relevant schema/docs text in the built runtime:

tools.sessions.visibility: Controls which sessions can be targeted by sessions_list/sessions_history/sessions_send. ("tree" default = current session + spawned subagent sessions; "self" = only current; "agent" = any session in the current agent id; "all" = any session; cross-agent still requires tools.agentToAgent).

Local recovery patch/config

To restore intentional Jarvis -> Billy/direct specialist access, I backed up config and added explicit scoped policy:

"tools": {
  "sessions": {
    "visibility": "all"
  },
  "agentToAgent": {
    "enabled": true,
    "allow": [
      "main",
      "billy",
      "farber",
      "scout",
      "maverick",
      "lumbergh"
    ]
  }
}

Then:

openclaw config validate
openclaw gateway restart --wait 120s
openclaw health --json
openclaw channels status --json

Validation after restart:

• config validates
• Gateway health OK
• Discord Jarvis/main connected after startup stagger
• no plugin load errors

Expected behavior

One of these should happen for multi-agent orchestration configs:

1. If agents.list[].subagents.allowAgents permits a target agent, direct agent-to-agent/session-send orchestration should either work automatically or produce a clear migration hint that mentions both required knobs: tools.sessions.visibility=all and tools.agentToAgent.enabled=true / tools.agentToAgent.allow.
2. openclaw doctor / config validate should warn when an agent has cross-agent delegation configured but the session tools policy blocks direct cross-agent send/history/status operations.
3. The error should not imply that only tools.sessions.visibility=all is required when tools.agentToAgent can be the next blocker.

Actual behavior

The first operator-visible failure only mentioned tools.sessions.visibility=all. It did not mention that cross-agent sends also need tools.agentToAgent, nor did doctor/config validation flag the mismatch between allowed subagents and blocked session sends.

Impact

Operators can misdiagnose this as target-agent failure or model/provider instability. In this case Billy also had separate provider timeout issues, but the direct Jarvis -> Billy health-check failure was OpenClaw-side policy gating, not CrofAI/model behavior.

Suggested fix

• Improve the forbidden error for cross-agent session send/history/status to include both required controls when applicable.
• Add a doctor/config lint for subagents.allowAgents or multi-agent orchestration configs where tools.sessions.visibility and tools.agentToAgent would block direct cross-agent access.
• Consider a migration prompt or guided config command for intentional multi-agent operators to enable a scoped tools.agentToAgent.allow list safely instead of requiring broad manual discovery.