Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Feature Request: Per-agent agentToAgent and session visibility scoping [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#59149•Fetched 2026-04-08 02:28:08
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
prasad-yashdeepprasad-yashdeep
Participants
prasad-yashdeepprasad-yashdeep
Timeline (top)
referenced ×2cross-referenced ×1

Fix Action

Fix / Workaround

Current behavior: Setting tools.sessions.visibility: "all" + tools.agentToAgent.enabled: true gives every agent access to every other agent's sessions and invocation capability. The only mitigation is soft enforcement via AGENTS.md instructions, which agents may not always follow.

Current Workaround

PR fix notes

PR #59170: feat: per-agent session visibility and agentToAgent scoping

Description (problem / solution / changelog)

Summary

Adds per-agent overrides for tools.sessions.visibility and tools.agentToAgent in agents.list[].tools config. When set, per-agent values take priority over global settings. Falls back to global when not set — fully backwards-compatible.

Resolves #59149

Problem

In multi-agent deployments, tools.sessions.visibility and tools.agentToAgent are global-only settings. This forces an all-or-nothing choice: either all agents can see all sessions, or none can. There is no way to give an orchestrator agent full access while restricting specialist agents to their own sessions.

Solution

Allow each agent in agents.list to specify its own sessions.visibility and agentToAgent config:

{
  "agents": {
    "list": [
      {
        "id": "orchestrator",
        "tools": {
          "sessions": { "visibility": "all" },
          "agentToAgent": { "enabled": true, "allow": ["*"] }
        }
      },
      {
        "id": "specialist",
        "tools": {
          "sessions": { "visibility": "self" },
          "agentToAgent": { "enabled": false }
        }
      }
    ]
  }
}

Precedence

  1. Per-agent config takes priority when explicitly set
  2. Falls back to global tools.sessions.visibility / tools.agentToAgent
  3. No per-agent config = identical behavior to current code

Changes

Schema

  • src/config/zod-schema.agent-runtime.ts — Added sessions and agentToAgent to AgentToolsSchema
  • src/config/types.tools.ts — Added corresponding TypeScript types

Core Logic

  • src/agents/tools/sessions-access.ts:
    • resolveSessionToolsVisibility() — accepts optional agentTools, per-agent takes priority
    • resolveEffectiveSessionToolsVisibility() — passes agentTools through
    • createAgentToAgentPolicy() — accepts optional requesterAgentTools, per-agent enabled and allow override global

Callers

  • sessions-list-tool.ts — resolves requester agent entry, passes tools
  • sessions-history-tool.ts — resolves requester agent entry, passes tools
  • sessions-send-tool.ts — resolves requester agent entry, passes tools
  • session-status-tool.ts — resolves requester agent entry, passes tools

Tests

  • 5 new test cases in sessions-access.test.ts:
    • Per-agent visibility overrides global
    • Falls back to global when per-agent not set
    • Per-agent agentToAgent.allow scopes targets (with wildcard support)
    • Per-agent agentToAgent.enabled=false overrides global
    • No per-agent config inherits global fully
  • 16/16 pass (5 new + 11 existing)

Docs

  • schema.labels.ts / schema.help.ts — field descriptions for Control UI
  • docs/tools/multi-agent-sandbox-tools.md — feature documentation with examples

Testing

pnpm test src/agents/tools/sessions-access.test.ts  # 16/16 pass
pnpm test  # 831/833 pass (2 pre-existing Matrix module failures)

Changed files

  • src/agents/tools/sessions-access.test.ts (modified, +65/-0)
  • src/agents/tools/sessions-access.ts (modified, +36/-6)
  • src/agents/tools/sessions-list-tool.ts (modified, +4/-1)
  • src/agents/tools/sessions-send-tool.ts (modified, +8/-5)
  • src/config/schema.help.ts (modified, +6/-0)
  • src/config/schema.labels.ts (modified, +3/-0)
  • src/config/sessions/repro-bug-15964.test.ts (added, +92/-0)
  • src/config/types.tools.ts (modified, +9/-0)
  • src/config/zod-schema.agent-runtime.ts (modified, +13/-0)

Code Example

{
  "id": "lead",
  "tools": {
    "sessions": {
      "visibility": "scoped",
      "visibleAgents": ["dev-1", "dev-2", "dev-3", "dev-4", "dev-5"]
    }
  }
}

---

{
  "id": "lead",
  "tools": {
    "agentToAgent": {
      "enabled": true,
      "allow": ["dev-1", "dev-2", "dev-3", "dev-4", "dev-5"]
    }
  }
}

---

{
  "id": "research",
  "tools": {
    "agentToAgent": {
      "receivesFrom": []  // nobody can invoke this agent
    }
  }
}
RAW_BUFFERClick to expand / collapse

Problem

In multi-agent deployments, tools.sessions.visibility and tools.agentToAgent are global-only settings. There is no way to scope these per-agent, which forces administrators into an all-or-nothing choice.

Example Scenario

Consider a 10-agent deployment with a hierarchical structure:

  • Orchestrator agent ("manager") — coordinates all other agents
  • Project lead agent ("lead") — coordinates a team of 5 specialist agents
  • 5 specialist agents ("dev-1" through "dev-5") — execute tasks for the lead
  • 2 support agents ("hr", "finance") — handle separate domains
  • 1 research agent ("research") — isolated, works independently

Desired access model:

AgentSession VisibilityCan Invoke
managerAll agentsAll agents
leaddev-1 through dev-5 onlydev-1 through dev-5 only
dev-1..5Own sessions onlyNobody (route through lead)
hr, financeOwn sessions onlyNobody
researchOwn sessions onlyNobody

Current behavior: Setting tools.sessions.visibility: "all" + tools.agentToAgent.enabled: true gives every agent access to every other agent's sessions and invocation capability. The only mitigation is soft enforcement via AGENTS.md instructions, which agents may not always follow.

Another Example

A company runs separate agents for:

  • Customer support (handles PII)
  • Engineering (has exec access)
  • Marketing (public-facing content)

The engineering agent should be able to check support agent's session for bug context, but the marketing agent should never see customer PII in support sessions. Today this is impossible without disabling cross-agent access entirely.

Proposed Solution

1. Per-agent sessions.visibility scope

Allow each agent in agents.list to specify which other agents' sessions it can access:

{
  "id": "lead",
  "tools": {
    "sessions": {
      "visibility": "scoped",
      "visibleAgents": ["dev-1", "dev-2", "dev-3", "dev-4", "dev-5"]
    }
  }
}

Options:

  • "self" — only own sessions (default for specialists)
  • "scoped" — only listed agents
  • "all" — everything (for orchestrators)

2. Per-agent agentToAgent allowlist

Allow each agent to define its own target allowlist:

{
  "id": "lead",
  "tools": {
    "agentToAgent": {
      "enabled": true,
      "allow": ["dev-1", "dev-2", "dev-3", "dev-4", "dev-5"]
    }
  }
}

An agent without agentToAgent in its config inherits the global setting but with an empty allow list (effectively disabled).

3. Bidirectional access control

Consider a receivesFrom counterpart:

{
  "id": "research",
  "tools": {
    "agentToAgent": {
      "receivesFrom": []  // nobody can invoke this agent
    }
  }
}

Current Workaround

Set global tools.sessions.visibility: "all" and tools.agentToAgent.enabled: true, then add soft guardrails in each specialist agent's AGENTS.md:

"Do NOT use sessions_send, sessions_history, or sessions_list to access other agents' sessions. Route all cross-team requests through your orchestrator."

This works in practice since agents follow their instructions, but it's not enforced at the platform level and provides no security guarantee.

Impact

This would benefit any multi-agent deployment with:

  • Hierarchical team structures (orchestrator → leads → specialists)
  • Data isolation requirements (PII, credentials, sensitive conversations)
  • Least-privilege access patterns
  • Mixed trust levels across agents

extent analysis

TL;DR

Implement per-agent settings for sessions.visibility and agentToAgent to enable fine-grained access control in multi-agent deployments.

Guidance

  • Introduce a scoped option for sessions.visibility to allow agents to specify which other agents' sessions they can access.
  • Define a per-agent agentToAgent allowlist to control which agents can invoke each other.
  • Consider adding a receivesFrom setting to enable bidirectional access control.
  • Update agent configurations to use the new settings, such as specifying visibleAgents for sessions.visibility and allow lists for agentToAgent.

Example

{
  "id": "lead",
  "tools": {
    "sessions": {
      "visibility": "scoped",
      "visibleAgents": ["dev-1", "dev-2", "dev-3", "dev-4", "dev-5"]
    },
    "agentToAgent": {
      "enabled": true,
      "allow": ["dev-1", "dev-2", "dev-3", "dev-4", "dev-5"]
    }
  }
}

Notes

The proposed solution requires updates to the platform's configuration and agent management systems. The new settings should be properly validated and documented to ensure correct usage.

Recommendation

Apply the proposed solution to implement per-agent access control settings, as it provides a more secure and flexible way to manage multi-agent deployments. This approach enables administrators to enforce least-privilege access patterns and ensures that sensitive data is properly isolated.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#API routing#API middleware#SSR setup#ISR setup#authentication setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING