Title: sessions_spawn cross-agent subagents run in requester workspace (cwd ignored), blocking separate agent workspace brains
Summary
When spawning a subagent via sessions_spawn with agentId="tech-support", the spawned run behaves as if its working directory/workspace context is still the requester agent’s workspace (~/.openclaw/workspace-pmi-assistant). Attempts to override with cwd did not change this behavior. This blocks a multi-agent setup where the delegated specialist must operate from its own seeded workspace (~/.openclaw/workspace-tech-support).
Environment
- OpenClaw: 2026.3.11 (29dc654)
- OS: macos 26.3 (arm64)
- Node: 22.22.1 (per
openclaw status)
- Gateway: local loopback
ws://127.0.0.1:18789 (reachable)
- Agents configured:
pmi-assistant (default), workspace ~/.openclaw/workspace-pmi-assistant
tech-support, workspace ~/.openclaw/workspace-tech-support
Relevant config (high level)
agents.list contains both pmi-assistant (default) and tech-support with distinct workspace paths.
agents.list.0.subagents.allowAgents includes tech-support (so spawning is allowed).
tools.agentToAgent.enabled=true, allow=["tech-support"] (also enabled, though core issue is sessions_spawn cwd/workspace behavior).
Reproduction steps
- Create two agents with distinct workspaces.
- Allow
pmi-assistant to spawn tech-support:
- set
agents.list.0.subagents.allowAgents to include tech-support
- confirm
agents_list shows tech-support
- From a
pmi-assistant session, call sessions_spawn with:
runtime: "subagent"
agentId: "tech-support"
- task instructing the child to read
./AGENTS.md + ./MEMORY.md and verify ./memory/* (files exist in ~/.openclaw/workspace-tech-support).
- Control test: call
sessions_spawn with cwd: "/tmp" and ask the child to run pwd.
Expected behavior
- If
agentId targets another agent, the spawned run should use the target agent’s workspace as default cwd (so relative paths and bootstrap/memory files resolve under that workspace).
- If
cwd is supported for runtime=subagent, it should be honored.
Actual behavior
- The spawned run consistently operates as if in
~/.openclaw/workspace-pmi-assistant.
- The
cwd parameter appears ignored for runtime=subagent.
Local evidence (transcript)
For a strict-evidence run under agent:tech-support:subagent:..., the session transcript header shows:
"cwd":"/Users/pmi.agent/.openclaw/workspace-pmi-assistant"
And the child’s tool calls read PMI workspace files, e.g.:
read /Users/pmi.agent/.openclaw/workspace-pmi-assistant/AGENTS.md
read /Users/pmi.agent/.openclaw/workspace-pmi-assistant/MEMORY.md (ENOENT)
Control test:
- spawn with
cwd=/tmp → child pwd still prints /Users/pmi.agent/.openclaw/workspace-pmi-assistant.
Docs note
The Session Tools docs for sessions_spawn do not mention a cwd parameter or workspace override semantics:
Questions
- Is this intended (subagents always inherit requester workspace) or a bug for cross-agent spawn?
- If intended, what is the supported mechanism to delegate work to another agent and ensure the target agent’s workspace bootstrap/memory are used?
- If a bug, should
sessions_spawn(agentId=...) set child cwd to the target agent workspace?
Title: sessions_spawn cross-agent subagents run in requester workspace (cwd ignored), blocking separate agent workspace brains
Summary
When spawning a subagent via
sessions_spawnwithagentId="tech-support", the spawned run behaves as if its working directory/workspace context is still the requester agent’s workspace (~/.openclaw/workspace-pmi-assistant). Attempts to override withcwddid not change this behavior. This blocks a multi-agent setup where the delegated specialist must operate from its own seeded workspace (~/.openclaw/workspace-tech-support).Environment
openclaw status)ws://127.0.0.1:18789(reachable)pmi-assistant(default), workspace~/.openclaw/workspace-pmi-assistanttech-support, workspace~/.openclaw/workspace-tech-supportRelevant config (high level)
agents.listcontains bothpmi-assistant(default) andtech-supportwith distinct workspace paths.agents.list.0.subagents.allowAgentsincludestech-support(so spawning is allowed).tools.agentToAgent.enabled=true,allow=["tech-support"](also enabled, though core issue issessions_spawncwd/workspace behavior).Reproduction steps
pmi-assistantto spawntech-support:agents.list.0.subagents.allowAgentsto includetech-supportagents_listshowstech-supportpmi-assistantsession, callsessions_spawnwith:runtime: "subagent"agentId: "tech-support"./AGENTS.md+./MEMORY.mdand verify./memory/*(files exist in~/.openclaw/workspace-tech-support).sessions_spawnwithcwd: "/tmp"and ask the child to runpwd.Expected behavior
agentIdtargets another agent, the spawned run should use the target agent’s workspace as default cwd (so relative paths and bootstrap/memory files resolve under that workspace).cwdis supported for runtime=subagent, it should be honored.Actual behavior
~/.openclaw/workspace-pmi-assistant.cwdparameter appears ignored for runtime=subagent.Local evidence (transcript)
For a strict-evidence run under
agent:tech-support:subagent:..., the session transcript header shows:"cwd":"/Users/pmi.agent/.openclaw/workspace-pmi-assistant"And the child’s tool calls read PMI workspace files, e.g.:
read /Users/pmi.agent/.openclaw/workspace-pmi-assistant/AGENTS.mdread /Users/pmi.agent/.openclaw/workspace-pmi-assistant/MEMORY.md(ENOENT)Control test:
cwd=/tmp→ childpwdstill prints/Users/pmi.agent/.openclaw/workspace-pmi-assistant.Docs note
The Session Tools docs for
sessions_spawndo not mention acwdparameter or workspace override semantics:Questions
sessions_spawn(agentId=...)set child cwd to the target agent workspace?