Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: subagents list still empty after spawn on v2026.4.29 [1 pull requests, 2 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#75593•Fetched 2026-05-02 05:32:56
View on GitHub
Comments
2
Participants
2
Timeline
3
Reactions
2
Author
aaajiaoaaajiao
Participants
aaajiaoaaajiaoclawsweeper[bot]clawsweeper[bot]
Timeline (top)
commented ×2cross-referenced ×1

/subagents list (and the agent-facing subagents(action="list") tool surface) still returns an empty list on v2026.4.29, even immediately after a subagent has been spawned and a childSessionKey was returned.

This appears to be a continuation of #71495, which was closed as fixed after the v2026.4.27 routing/registry changes. I attempted to reopen #71495, but the token available in my environment cannot call reopenIssue, so I'm filing this follow-up with fresh v2026.4.29 evidence.

Root Cause

This is not just cosmetic. When the parent session is coordinating subagents, an empty list makes it impossible to inspect, steer, or kill recently spawned child work from the requester session. It also makes it hard to debug cases where the completion event is missing or delayed.

Fix Action

Fixed

PR fix notes

PR #75679: fix(agents): canonicalize subagent list requester keys

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

If this PR fixes a plugin beta-release blocker, title it fix(<plugin-id>): beta blocker - <summary> and link the matching Beta blocker: <plugin-name> - <summary> issue labeled beta-blocker. Contributors cannot label PRs, so the title is the PR-side signal for maintainers and automation.

  • Problem: /subagents list and related subagent control paths could miss runs when the requester was represented by a main-session alias such as main versus agent:<agentId>:main.
  • Why it matters: Users could spawn subagents successfully but fail to list or control them from the main session, making background work appear lost.
  • What changed: Canonicalized main-session requester/controller keys at the subagent list/ control boundaries and added regression coverage for both tool and slash-command paths.
  • What did NOT change (scope boundary): No changes to spawn semantics, permissions, session storage schema, thread binding, delivery behavior, or plugin APIs.

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

  • Closes #75593
  • Related #
  • This PR fixes a bug or regression

Root Cause (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

  • Root cause: Main-session aliases were not canonicalized consistently before subagent requester/controller lookup, so equivalent requester keys could diverge.
  • Missing detection / guardrail: Existing tests did not cover listing or routing subagents across equivalent main-session aliases.
  • Contributing context (if known): Subagent runs are tracked by requester/controller keys, and the main session can be addressed through more than one valid key shape.

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should catch this. Otherwise write N/A.

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
    • Target test or file:
      • src/agents/openclaw-tools.subagents.scope.test.ts
      • src/auto-reply/reply/commands-subagents-routing.test.ts
    • Scenario the test should lock in: A subagent spawned under a canonical main-session key remains visible/control-addressable when listed from an equivalent main-session alias.
    • Why this is the smallest reliable guardrail: The bug was in requester/controller key normalization, so focused tool and command tests cover the affected lookup boundaries without broad E2E setup.
    • Existing test that already covers this (if any): None for the alias mismatch case.
    • If no new test is added, why not: N/A

User-visible / Behavior Changes

/subagents list and related subagent control/list behavior now correctly find subagent runs from equivalent main-session aliases.

Diagram (if applicable)

For UI changes or non-trivial logic flows, include a small ASCII diagram reviewers can scan quickly. Otherwise write N/A.

  Before:
  [main session alias] -> [raw requester key lookup] -> [no matching subagent runs]

  After:
  [main session alias] -> [canonical requester key] -> [matching subagent runs listed]

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

  • OS: macOS local workstation
  • Runtime/container: Local Node/pnpm workspace
  • Model/provider: N/A
  • Integration/channel (if any): Subagents tool and slash-command routing
  • Relevant config (redacted): N/A

Steps

  1. Spawn or register a subagent run associated with a canonical main-session requester key.
  2. Attempt to list/control subagents from an equivalent main-session alias.
  3. Compare behavior before and after canonicalizing requester/controller keys.

Expected

  • Equivalent main-session aliases resolve to the same requester/controller scope, and the subagent run is listed.

Actual

  • Before this fix, alias mismatch could return no runs.
  • After this fix, the run is found consistently.

Evidence

Attach at least one:

  • Failing test/log before + passing after

  • Trace/log snippets

  • Screenshot/recording

  • Perf numbers (if relevant) Targeted verification passed:

    • pnpm test src/agents/openclaw-tools.subagents.scope.test.ts src/auto-reply/reply/commands- subagents-routing.test.ts src/agents/subagent-control.test.ts src/agents/subagent-list.test.ts src/agents/tools/sessions-spawn-tool.test.ts src/auto-reply/reply/commands-subagents-spawn- action.test.ts
    • pnpm build
    • pnpm check:changed
    • codex review --base origin/main

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios:
    • Main-session alias lookup fails before the fix and succeeds after the fix.
    • Tool-path subagent listing resolves equivalent main-session aliases.
    • Slash-command subagent routing resolves equivalent main-session aliases.
  • Edge cases checked:
    • Existing subagent control/list tests still pass.
    • Existing spawn-action tests still pass.
  • What you did not verify:
    • Live channel delivery in an external messaging integration.
    • Remote CI/Testbox execution.

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.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps: N/A

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

  • Risk: Canonicalizing aliases could unintentionally affect subagent lookup scope.
    • Mitigation: The change is limited to main-session alias normalization at requester/ controller resolution boundaries and is covered by focused regression tests for both tool and command paths.

Built with Codex

Changed files

  • src/agents/openclaw-tools.subagents.scope.test.ts (modified, +31/-0)
  • src/agents/subagent-control.ts (modified, +13/-1)
  • src/auto-reply/reply/commands-subagents-routing.test.ts (modified, +28/-1)
  • src/auto-reply/reply/commands-subagents/shared.ts (modified, +13/-1)

Code Example

{
  "status": "accepted",
  "childSessionKey": "agent:main:subagent:7deb3aee-6c38-4e8f-bb2b-919d-fe9f88dbe9b0",
  "runId": "c44c33a4-99d8-4c4b-936a-105249683e21",
  "mode": "run"
}

---

active subagents:
(none)

recent (last 120m):
(none)

---

{
  "status": "accepted",
  "childSessionKey": "agent:main:subagent:d9171f6f-cd35-4b2d-919d-fe9f88dbe9b0",
  "runId": "5eea2c30-c0cc-4ace-b55e-f0aee1a62ddd",
  "mode": "run"
}

---

active subagents:
(none)

recent (last 60m):
(none)
RAW_BUFFERClick to expand / collapse

Summary

/subagents list (and the agent-facing subagents(action="list") tool surface) still returns an empty list on v2026.4.29, even immediately after a subagent has been spawned and a childSessionKey was returned.

This appears to be a continuation of #71495, which was closed as fixed after the v2026.4.27 routing/registry changes. I attempted to reopen #71495, but the token available in my environment cannot call reopenIssue, so I'm filing this follow-up with fresh v2026.4.29 evidence.

Fresh evidence on v2026.4.29

A subagent spawn was accepted and returned a concrete child session key:

{
  "status": "accepted",
  "childSessionKey": "agent:main:subagent:7deb3aee-6c38-4e8f-bb2b-919d-fe9f88dbe9b0",
  "runId": "c44c33a4-99d8-4c4b-936a-105249683e21",
  "mode": "run"
}

Shortly afterwards, listing recent subagents from the same requester session returned empty:

active subagents:
(none)

recent (last 120m):
(none)

The same happened with a previous subagent in the same session:

{
  "status": "accepted",
  "childSessionKey": "agent:main:subagent:d9171f6f-cd35-4b2d-919d-fe9f88dbe9b0",
  "runId": "5eea2c30-c0cc-4ace-b55e-f0aee1a62ddd",
  "mode": "run"
}

But later:

active subagents:
(none)

recent (last 60m):
(none)

So the spawn path returns/knows a subagent session key, but the list/read path visible to the parent session does not show active or recent subagents.

Expected

After sessions_spawn / native subagent spawn returns childSessionKey, subagents list should show that run as active or recent within the requested recent window.

Actual

The list surface returns (none) for both active and recent, even with recentMinutes=60 or recentMinutes=120.

Why this matters

This is not just cosmetic. When the parent session is coordinating subagents, an empty list makes it impossible to inspect, steer, or kill recently spawned child work from the requester session. It also makes it hard to debug cases where the completion event is missing or delayed.

Related

Environment

  • OpenClaw: v2026.4.29
  • Runtime shown in session: agent=main, host=openclaw-vm, model=openai-codex/gpt-5.5
  • OS/runtime context: Linux 6.19.13-orbstack-gbd1dc07b8cf4 arm64, Node v24.14.0
  • Channel: Telegram direct session

extent analysis

TL;DR

The issue with subagents not being listed after spawning, even with a returned childSessionKey, may require re-examining the fixes applied in v2026.4.27 and ensuring they are correctly implemented for all scenarios.

Guidance

  • Review the changes made in v2026.4.27 for issue #71495 to understand how subagent listing was supposed to be fixed and verify if these changes are correctly applied in v2026.4.29.
  • Check the logging and debugging information for any errors or warnings related to subagent spawning and listing to identify potential issues.
  • Test the subagent spawning and listing process with different parameters (e.g., varying recentMinutes) to see if the issue is consistent across different scenarios.
  • Consider temporarily modifying the logging level or adding debug statements to the subagent listing code to gain more insight into why the list remains empty.

Example

No specific code example can be provided without more context on the implementation details of the subagent spawning and listing functionality.

Notes

The issue seems to be a regression or a missed edge case from the fixes applied for #71495. The fact that the childSessionKey is returned but the subagent does not appear in the list suggests a potential issue with the listing mechanism or the data storage/retrieval process.

Recommendation

Apply a workaround by manually tracking spawned subagents in the parent session until the listing issue is resolved, as the empty list hampers the ability to inspect, steer, or kill child work.

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…
#latency issue#model loading#dependency error#configuration error#environment variable

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: subagents list still empty after spawn on v2026.4.29 [1 pull requests, 2 comments, 2 participants]