Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: agents.defaults.subagents.allowAgents is silently ignored and must be set per-agent in agents.list [4 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#59938•Fetched 2026-04-08 02:38:35
View on GitHub
Comments
0
Participants
1
Timeline
13
Reactions
0
Author
chelizardchelizard
Participants
chelizardchelizard
Timeline (top)
referenced ×5cross-referenced ×4labeled ×2closed ×1

When configuring multi-agent setups, setting allowAgents inside agents.defaults.subagents has no effect at runtime. Despite agents being correctly registered and visible in openclaw agents list, any call to sessions_spawn with an explicit agentId returns allowed: none. The config key is accepted without error, which makes this particularly hard to debug — everything looks correct but spawning is completely blocked.

The fix is to set allowAgents directly on the spawning agent's entry in agents.list[n].subagents rather than in defaults. This is not documented and the behavior of defaults silently not propagating is unexpected given that other subagent keys like model, maxConcurrent, and runTimeoutSeconds do inherit from defaults correctly.

Error Message

When configuring multi-agent setups, setting allowAgents inside agents.defaults.subagents has no effect at runtime. Despite agents being correctly registered and visible in openclaw agents list, any call to sessions_spawn with an explicit agentId returns allowed: none. The config key is accepted without error, which makes this particularly hard to debug — everything looks correct but spawning is completely blocked. 5. Observe error: Spawn failed: agentId is not allowed for sessions_spawn (allowed: none) The allowAgents key in defaults is silently ignored. The spawn handler sees allowed: none regardless of what's in defaults. The config validates without error and openclaw agents list shows all agents correctly, giving no indication anything is misconfigured. Consequence: Multi-agent workflows cannot be initiated at all. The practical consequence is that any automation or orchestration pattern that relies on a main agent spawning named subagents is completely blocked until the workaround is applied. The workaround is non-obvious because the config accepts the key without error, openclaw agents list shows all agents as registered, and the gateway reports healthy... there is no signal in normal operation that defaults are being ignored. It's annoying.

Root Cause

Consequence: Multi-agent workflows cannot be initiated at all. The practical consequence is that any automation or orchestration pattern that relies on a main agent spawning named subagents is completely blocked until the workaround is applied. The workaround is non-obvious because the config accepts the key without error, openclaw agents list shows all agents as registered, and the gateway reports healthy... there is no signal in normal operation that defaults are being ignored. It's annoying.

Fix Action

Fix / Workaround

Workaround:

Set allowAgents directly on the spawning agent in agents.list:

Consequence: Multi-agent workflows cannot be initiated at all. The practical consequence is that any automation or orchestration pattern that relies on a main agent spawning named subagents is completely blocked until the workaround is applied. The workaround is non-obvious because the config accepts the key without error, openclaw agents list shows all agents as registered, and the gateway reports healthy... there is no signal in normal operation that defaults are being ignored. It's annoying.

PR fix notes

PR #59944: fix(agents): fall back to defaults for subagents.allowAgents

Description (problem / solution / changelog)

lobster-biscuit

Closes #59938

Problem

Setting allowAgents in agents.defaults.subagents has no effect. Despite agents being correctly registered, sessions_spawn returns allowed: none. Only setting allowAgents directly on the per-agent entry works.

Other subagent defaults like runTimeoutSeconds and maxConcurrent correctly inherit from agents.defaults.subagents — allowAgents was missed.

Root cause

src/agents/subagent-spawn.ts:463 and src/agents/tools/agents-list-tool.ts:49 — both read resolveAgentConfig(cfg, agentId)?.subagents?.allowAgents which returns only the per-agent config. No fallback to cfg.agents.defaults.subagents.allowAgents.

The established pattern (line 403 for runTimeoutSeconds) reads from cfg.agents.defaults.subagents directly.

User impact

Multi-agent setups silently broken. allowAgents in defaults does nothing — everything looks correct but spawning is completely blocked. Hard to debug because config is accepted without error.

Fix

Add cfg.agents.defaults.subagents.allowAgents as fallback at both call sites. Matches existing pattern for runTimeoutSeconds.

2 files, +6/-2.

How to verify

  1. Set agents.defaults.subagents.allowAgents: ["researcher"]
  2. sessions_spawn with agentId: "researcher"
  3. Before: allowed: none. After: spawns correctly.

Generated with Claude Code

Changed files

  • src/agents/subagent-spawn.ts (modified, +4/-1)
  • src/agents/tools/agents-list-tool.ts (modified, +4/-1)

PR #59947: fix(subagents): allowAgents falls back to agents.defaults.subagents

Description (problem / solution / changelog)

Summary

When is set in rather than on the individual agent's config, it was silently ignored. Every call with an explicit returned allowed: none.

Root Cause

In src/agents/subagent-spawn.ts, the variable was resolved with only one fallback step:

const allowAgents = resolveAgentConfig(cfg, requesterAgentId)?.subagents?.allowAgents ?? [];

But resolveAgentConfig() returns only the agent's own config — it does not merge with agents.defaults. Meanwhile, requireAgentId (three lines above, same pattern) already had the correct two-step fallback:

const requireAgentId =
  resolveAgentConfig(cfg, requesterAgentId)?.subagents?.requireAgentId ??
  cfg.agents?.defaults?.subagents?.requireAgentId ??
  false;

The fix adds the same defaults fallback to .

Fix

const allowAgents =
  resolveAgentConfig(cfg, requesterAgentId)?.subagents?.allowAgents ??
  cfg.agents?.defaults?.subagents?.allowAgents ??
  [];

Testing

Added two regression tests:

  1. sessions_spawn reads allowAgents from agents.defaults.subagents — verifies that when allowAgents is only in defaults, cross-agent spawning is allowed
  2. sessions_spawn per-agent allowAgents overrides agents.defaults.subagents — verifies per-agent config still takes priority over defaults

All 17 allowlist tests pass.

Fixes #59938.

Changed files

  • src/agents/openclaw-tools.subagents.sessions-spawn.allowlist.test.ts (modified, +52/-0)
  • src/agents/subagent-spawn.ts (modified, +4/-1)

PR #60072: fix(subagents): honor default allowAgents

Description (problem / solution / changelog)

Summary

  • fall back to agents.defaults.subagents.allowAgents when an agent entry does not override it
  • apply the same fallback to agents_list so the visible allowlist matches spawn behavior
  • add regression coverage for both sessions_spawn and agents_list

Testing

  • pnpm.cmd exec vitest run src/agents/openclaw-tools.subagents.sessions-spawn.allowlist.test.ts
  • pnpm.cmd exec vitest run src/agents/openclaw-tools.agents.test.ts
  • pnpm.cmd lint src/agents/subagent-spawn.ts src/agents/tools/agents-list-tool.ts src/agents/openclaw-tools.subagents.sessions-spawn.allowlist.test.ts src/agents/openclaw-tools.agents.test.ts

Closes #59938.

Changed files

  • src/agents/openclaw-tools.agents.test.ts (modified, +28/-0)
  • src/agents/openclaw-tools.subagents.sessions-spawn.allowlist.test.ts (modified, +26/-0)
  • src/agents/subagent-spawn.ts (modified, +4/-1)
  • src/agents/tools/agents-list-tool.ts (modified, +4/-1)
  • src/config/types.agent-defaults.ts (modified, +2/-0)

PR #60120: fix(agents): honor defaults subagent allowlist for sessions_spawn

Description (problem / solution / changelog)

Motivation

agents.defaults.subagents.allowAgents was accepted by config but ignored by runtime allowlist checks. As a result, cross-agent sessions_spawn failed unless allowAgents was duplicated per-agent in agents.list, which caused confusing allowed: none behavior.

Fixes #59938

Changes

  • make sessions_spawn allowlist resolution fall back to agents.defaults.subagents.allowAgents when agent-level subagents.allowAgents is unset
  • apply the same fallback in agents_list so discovery output matches actual spawn authorization behavior
  • add allowAgents?: string[] to AgentDefaultsConfig.subagents
  • extend AgentDefaultsSchema to validate defaults.subagents.allowAgents
  • add regression tests for default-level allowlist behavior in sessions_spawn, agents_list, and schema parsing

Testing

  • pnpm test -- src/config/zod-schema.agent-defaults.test.ts src/agents/openclaw-tools.subagents.sessions-spawn.allowlist.test.ts src/agents/openclaw-tools.agents.test.ts

Changed files

  • src/agents/openclaw-tools.agents.test.ts (modified, +28/-0)
  • src/agents/openclaw-tools.subagents.sessions-spawn.allowlist.test.ts (modified, +30/-0)
  • src/agents/subagent-spawn.ts (modified, +4/-1)
  • src/agents/tools/agents-list-tool.ts (modified, +4/-1)
  • src/config/types.agent-defaults.ts (modified, +2/-0)
  • src/config/zod-schema.agent-defaults.test.ts (modified, +10/-0)
  • src/config/zod-schema.agent-defaults.ts (modified, +1/-0)

Code Example

{
  "agents": {
    "defaults": {
      "subagents": {
        "allowAgents": ["researcher", "qa"],
        "maxConcurrent": 3,
        "runTimeoutSeconds": 300
      }
    },
    "list": [
      { "id": "main" },
      { "id": "researcher" },
      { "id": "qa" }
    ]
  }
}

---

{
  "agents": {
    "list": [
      {
        "id": "main",
        "subagents": {
          "allowAgents": ["researcher", "qa"]
        }
      },
      { "id": "researcher" },
      { "id": "qa" }
    ]
  }
}

---

openclaw config set agents.list[0].subagents.allowAgents '["researcher", "qa"]' --json
openclaw gateway restart

---
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

When configuring multi-agent setups, setting allowAgents inside agents.defaults.subagents has no effect at runtime. Despite agents being correctly registered and visible in openclaw agents list, any call to sessions_spawn with an explicit agentId returns allowed: none. The config key is accepted without error, which makes this particularly hard to debug — everything looks correct but spawning is completely blocked.

The fix is to set allowAgents directly on the spawning agent's entry in agents.list[n].subagents rather than in defaults. This is not documented and the behavior of defaults silently not propagating is unexpected given that other subagent keys like model, maxConcurrent, and runTimeoutSeconds do inherit from defaults correctly.

Steps to reproduce

  1. Register multiple agents in openclaw.json:
{
  "agents": {
    "defaults": {
      "subagents": {
        "allowAgents": ["researcher", "qa"],
        "maxConcurrent": 3,
        "runTimeoutSeconds": 300
      }
    },
    "list": [
      { "id": "main" },
      { "id": "researcher" },
      { "id": "qa" }
    ]
  }
}
  1. Restart the gateway: openclaw gateway restart
  2. Confirm all agents are registered: openclaw agents list (all three appear correctly)
  3. From your main agent session, attempt to spawn a subagent with a specific agentId: /subagents spawn <agent name> test
  4. Observe error: Spawn failed: agentId is not allowed for sessions_spawn (allowed: none)

Expected behavior

allowAgents set in agents.defaults.subagents should propagate to all registered agents at spawn time, the same way model, maxConcurrent, and runTimeoutSeconds inherit from defaults. Setting it in defaults should be equivalent to setting it on each agent individually.

Actual behavior

The allowAgents key in defaults is silently ignored. The spawn handler sees allowed: none regardless of what's in defaults. The config validates without error and openclaw agents list shows all agents correctly, giving no indication anything is misconfigured.

Workaround:

Set allowAgents directly on the spawning agent in agents.list:

{
  "agents": {
    "list": [
      {
        "id": "main",
        "subagents": {
          "allowAgents": ["researcher", "qa"]
        }
      },
      { "id": "researcher" },
      { "id": "qa" }
    ]
  }
}

Or via CLI:

openclaw config set agents.list[0].subagents.allowAgents '["researcher", "qa"]' --json
openclaw gateway restart

(Use ["*"] to allow spawning any registered agent)

Note: maxSpawnDepth: 2 is also required in agents.defaults.subagents for orchestrator-style spawning — without it, agents don't receive sessions_spawn in their toolset regardless of allowAgents. (see documentation)

OpenClaw version

2026.4.2

Operating system

Ubuntu 24.04.4 LTS

Install method

No response

Model

anthropic/claude-sonnet-4-6

Provider / routing chain

openclaw → linux → node → telegram -> gateway

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Affected: Any user attempting to set up a multi-agent configuration using agents.defaults.subagents.allowAgents. Specifically affects the Telegram channel based on observed evidence, though the bug is at the config/runtime layer so it would affect any channel. Affects OpenClaw 2026.4.2 on Linux, not sure about else.

Severity: Blocks workflow completely. Multi-agent orchestration is entirely non-functional when configured via defaults. There is no degraded mode, spawning fails 100% of the time with no fallback behavior.

Frequency: Always reproduces. Every sessions_spawn call with an explicit agentId fails when allowAgents is set only in defaults. No intermittency observed, it is a deterministic config resolution bug.

Consequence: Multi-agent workflows cannot be initiated at all. The practical consequence is that any automation or orchestration pattern that relies on a main agent spawning named subagents is completely blocked until the workaround is applied. The workaround is non-obvious because the config accepts the key without error, openclaw agents list shows all agents as registered, and the gateway reports healthy... there is no signal in normal operation that defaults are being ignored. It's annoying.

Additional information

No response

extent analysis

TL;DR

To fix the issue with allowAgents not propagating from agents.defaults.subagents, set allowAgents directly on the spawning agent's entry in agents.list[n].subagents.

Guidance

  • The issue arises from a configuration resolution bug where allowAgents set in agents.defaults.subagents is silently ignored at runtime.
  • To verify the issue, attempt to spawn a subagent with a specific agentId using sessions_spawn and observe the allowed: none error.
  • Apply the workaround by setting allowAgents directly on the spawning agent in agents.list, either through the config file or using the CLI command openclaw config set agents.list[0].subagents.allowAgents '["researcher", "qa"]' --json.
  • Ensure maxSpawnDepth: 2 is also set in agents.defaults.subagents for orchestrator-style spawning to work correctly.

Example

Setting allowAgents directly on the spawning agent:

{
  "agents": {
    "list": [
      {
        "id": "main",
        "subagents": {
          "allowAgents": ["researcher", "qa"]
        }
      },
      { "id": "researcher" },
      { "id": "qa" }
    ]
  }
}

Notes

This fix applies to OpenClaw version 2026.4.2 on Linux. The behavior of other versions or operating systems is unknown.

Recommendation

Apply the workaround by setting allowAgents directly on the spawning agent, as this is the only known solution to the configuration resolution bug.

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…

FAQ

Expected behavior

allowAgents set in agents.defaults.subagents should propagate to all registered agents at spawn time, the same way model, maxConcurrent, and runTimeoutSeconds inherit from defaults. Setting it in defaults should be equivalent to setting it on each agent individually.

#retriever error#indexing error#inference speed#output truncation#agent 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