Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix ACP child sessions spawned by a parent agent are not readable via sessions_history without cross-agent allowlist [3 pull requests, 1 comments, 2 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#54878•Fetched 2026-04-08 01:34:55
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
2
Author
1sexywoo81sexywoo8
Participants
1sexywoo81sexywoo8da1zda1z
Timeline (top)
cross-referenced ×4commented ×1

Parent agents can successfully spawn ACP child sessions, but cannot read those child sessions back with sessions_history unless the ACP harness agent id (for example codex) is manually added to tools.agentToAgent.allow.

This makes ACP orchestration half-functional: spawn works, but result retrieval is blocked.

Root Cause

ACP becomes much less useful if tasks can be spawned but not observed/retrieved from the parent workflow.

PR fix notes

PR #55983: sessions: tree visibility honors spawn lineage before cross-agent gate [AI assisted with amp code]

Description (problem / solution / changelog)

Summary

  • Problem: createSessionVisibilityGuard checked isCrossAgent before consulting the spawned-session set. A parent session (agent:main:main) that spawned a child with a different agent id (e.g. agent:opencode:acp:<uuid>) was blocked from reading the child's history with "Set tools.sessions.visibility=all to allow cross-agent access" — even though tree visibility is documented as "current session + sessions spawned by this session."
  • Why it matters: ACP and other spawn-based workflows produce children whose session keys carry a different agent prefix. Those children are unreachable under the default config, breaking sessions_history, session_status, etc.
  • What changed: Restructured the check() closure in createSessionVisibilityGuard so that in tree mode the spawned-set membership is evaluated first; spawned children are allowed regardless of agent id.
  • What did NOT change (scope boundary): self, agent, and all visibility modes are unchanged. Cross-agent gating for non-spawned targets in tree mode still rejects. AgentToAgentPolicy logic is untouched.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

  • Root cause: The isCrossAgent early-return in createSessionVisibilityGuard (line 203-209) ran before the tree/spawned-set check, so any target with a different agent id prefix was rejected unconditionally when visibility was not all.
  • Missing detection / guardrail: No test covered tree visibility with a cross-agent spawned child key.
  • Prior context: The cross-agent gate was added as a security boundary but did not account for spawn lineage.
  • Why this regressed now: ACP agent spawn produces child keys with agent:opencode:acp:… which differ from the parent's agent:main:… prefix.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
  • Target test or file: src/agents/tools/sessions-access.test.ts
  • Scenario the test should lock in: Parent agent:main:main with tree visibility and a2a disabled; gateway returns a spawned child agent:opencode:acp:<uuid>; guard.check(childKey) must return { allowed: true }.
  • Why this is the smallest reliable guardrail: Pure unit test on createSessionVisibilityGuard with a mocked gateway — no integration surface needed.

User-visible / Behavior Changes

Session tools (sessions_history, session_status, etc.) now allow reading spawned child sessions with a different agent id under the default tree visibility, matching the documented behavior.

Diagram (if applicable)

Before:
[parent agent:main:main] -> sessions_history(agent:opencode:acp:…) -> FORBIDDEN (cross-agent gate)

After:
[parent agent:main:main] -> sessions_history(agent:opencode:acp:…) -> ALLOWED (in spawned set)

Security Impact (required)

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? No
  • Command/tool execution surface changed? No
  • Data access scope changed? No — spawned children were already listed by sessions.list and visible in the spawn tree; only the guard's check order was wrong.

Repro + Verification

Steps

  1. Configure default tools.sessions.visibility (tree), no agentToAgent config.
  2. Spawn a child session whose key has a different agent id (e.g. ACP agent).
  3. Call sessions_history targeting the child key.

Expected

  • Access allowed (child is in the spawn tree).

Actual (before fix)

  • Forbidden: "Set tools.sessions.visibility=all to allow cross-agent access."

Evidence

  • Failing test/log before + passing after

New test "tree visibility allows spawned child with a different agent id" in sessions-access.test.ts — confirmed RED before fix, GREEN after.

Human Verification (required)

  • Verified scenarios: pnpm test -- src/agents/tools/sessions-access.test.ts src/agents/openclaw-tools.sessions-visibility.test.ts — 16/16 pass.
  • Edge cases checked: Existing tests cover same-agent tree, self visibility, cross-agent send with a2a disabled, large spawned-set cap.
  • What you did not verify: Full e2e with a real ACP agent spawn.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? Yes
  • Config/env changes? No
  • Migration needed? No

Risks and Mitigations

  • None — the change only reorders checks within tree mode so spawned children bypass the cross-agent gate, which matches documented behavior.

AMP thread: https://ampcode.com/threads/T-019d3097-bb5a-7766-a00b-668607d0a387

Changed files

  • src/agents/tools/sessions-access.test.ts (modified, +35/-0)
  • src/agents/tools/sessions-access.ts (modified, +18/-12)

PR #56019: fix(sessions): honor spawned tree lineage across agents

Description (problem / solution / changelog)

Summary

  • allow spawned ACP child sessions when tools.sessions.visibility is set to tree, even when the child session key belongs to a different agent: id
  • add a guard-level regression test for spawned cross-agent child visibility
  • add a tool-level regression test proving sessions_history now returns the spawned child session

Root Cause

The visibility guard rejected cross-agent session keys before considering whether the target session belonged to the caller's spawned session tree. Spawned ACP child sessions therefore stayed hidden even under tree visibility.

Scope

  • changes only the session visibility guard and the related visibility tests
  • does not broaden generic cross-agent access outside the existing spawned-tree lineage rules

Testing

  • pnpm exec vitest run src/agents/tools/sessions-access.test.ts src/agents/openclaw-tools.sessions-visibility.test.ts
  • pnpm build
  • pnpm check
  • pnpm test

Screenshots

  • Not applicable

Closes #54878

Changed files

  • src/agents/openclaw-tools.sessions-visibility.test.ts (modified, +26/-0)
  • src/agents/tools/sessions-access.test.ts (modified, +29/-0)
  • src/agents/tools/sessions-access.ts (modified, +9/-0)

PR #56028: fix(sessions): honor spawned tree lineage across agents

Description (problem / solution / changelog)

Summary

  • allow spawned ACP child sessions when tools.sessions.visibility is set to tree, even when the child session key belongs to a different agent: id
  • add a guard-level regression test for spawned cross-agent child visibility
  • add a tool-level regression test proving sessions_history now returns the spawned child session

Root Cause

The visibility guard rejected cross-agent session keys before considering whether the target session belonged to the caller's spawned session tree. Spawned ACP child sessions therefore stayed hidden even under tree visibility.

Scope

  • changes only the session visibility guard and the related visibility tests
  • does not broaden generic cross-agent access outside the existing spawned-tree lineage rules

Testing

  • pnpm exec vitest run src/agents/tools/sessions-access.test.ts src/agents/openclaw-tools.sessions-visibility.test.ts
  • pnpm build
  • pnpm check
  • pnpm test

Screenshots

  • Not applicable

Resubmission of #56019 after active PR queue cleanup. No code changes from the original submission.

Closes #54878

Changed files

  • src/agents/openclaw-tools.sessions-visibility.test.ts (modified, +26/-0)
  • src/agents/tools/sessions-access.test.ts (modified, +29/-0)
  • src/agents/tools/sessions-access.ts (modified, +9/-0)
RAW_BUFFERClick to expand / collapse

Summary

Parent agents can successfully spawn ACP child sessions, but cannot read those child sessions back with sessions_history unless the ACP harness agent id (for example codex) is manually added to tools.agentToAgent.allow.

This makes ACP orchestration half-functional: spawn works, but result retrieval is blocked.

Repro

Environment:

  • OpenClaw with acpx runtime installed/enabled
  • tools.sessions.visibility = "all"
  • tools.agentToAgent.enabled = true
  • tools.agentToAgent.allow includes the parent agent (for example communicator) but not the ACP harness id (for example codex)

Steps:

  1. From an agent session (for example agent:communicator:main), call:
    • sessions_spawn(runtime="acp", agentId="codex", mode="run", task="Reply with exactly OK")
  2. Observe spawn is accepted and a real childSessionKey like agent:codex:acp:<uuid> is returned.
  3. Call:
    • sessions_history(sessionKey=<childSessionKey>)

Actual result

sessions_history returns:

Agent-to-agent history denied by tools.agentToAgent.allow.

Expected result

A parent agent should be able to inspect its own spawned ACP/subagent child sessions without requiring broad cross-agent allowlist membership for the harness agent id.

Reading a parent-owned child session should be treated as parent/child lineage visibility, not as generic cross-agent access.

Notes / investigation

  • Child lineage metadata exists: parent sessions list ACP child session keys in childSessions.
  • This appears related to createSessionVisibilityGuard and the ordering/shape of cross-agent checks.
  • A narrow policy seems preferable to the quick fix of adding codex to tools.agentToAgent.allow.
  • Suggested direction: parent-owned spawned child sessions (especially subagent:* / acp:* lineage) should be readable by the spawning parent regardless of differing agent ids.

Why this matters

ACP becomes much less useful if tasks can be spawned but not observed/retrieved from the parent workflow.

extent analysis

Fix Plan

To fix this issue, we need to modify the createSessionVisibilityGuard function to allow parent agents to read their own spawned ACP child sessions without requiring the ACP harness agent id to be in the tools.agentToAgent.allow list.

Here are the steps to fix the issue:

  • Modify the createSessionVisibilityGuard function to check if the requesting agent is the parent of the session being requested.
  • If the requesting agent is the parent, allow the request to proceed without checking the tools.agentToAgent.allow list.

Example code snippet:

function createSessionVisibilityGuard(sessionKey, requestingAgentId) {
  // ... existing code ...

  // Check if the requesting agent is the parent of the session
  const parentAgentId = getSessionParentAgentId(sessionKey);
  if (parentAgentId === requestingAgentId) {
    // Allow the request to proceed if the requesting agent is the parent
    return true;
  }

  // ... existing code to check tools.agentToAgent.allow ...
}

Verification

To verify that the fix worked, follow these steps:

  • Spawn an ACP child session from a parent agent using sessions_spawn.
  • Call sessions_history with the child session key without adding the ACP harness agent id to tools.agentToAgent.allow.
  • Verify that the sessions_history call returns the expected result without returning an "Agent-to-agent history denied" error.

Extra Tips

  • Make sure to test the fix with different scenarios, including spawning multiple child sessions and verifying that the parent agent can read all of them.
  • Consider adding additional logging or monitoring to ensure that the fix does not introduce any security vulnerabilities.

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…
#serialization error#model compatibility#GPU setup#container setup#orchestration issue

Still need to ship something?

×6

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

Back to top recommendations

TRENDING