Subagent workspace isolation means every agent OpenClaw spawns gets its own working directory, its own copy of the task context, and its own session lock, so two agents running at the same time can’t overwrite each other’s files or read each other’s half-finished state. The v2026.5.28 release hardened exactly this: spawned agents now keep their cwd and workspace separated, hook context stays prompt-local, and session locks release on a timeout abort instead of wedging the whole runtime.
If you run one agent, none of this matters. The moment you run a team (a builder, a researcher, a writer, all going at once) it becomes the difference between finished work in the morning and a pile of clobbered files.
Why parallel agents corrupt shared state
The failure is boring and predictable. Two agents share one working directory. Agent A writes report.md. Agent B, mid-task, also writes report.md. Whoever finishes last wins, and the other agent’s work is gone. Silently, with no error.
It gets worse with context. If a subagent inherits the orchestrator’s full live context instead of a scoped copy, a stray instruction meant for one agent bleeds into another. The builder starts following the writer’s prompt. Developers running parallel coding agents hit this constantly; the common workaround in the wider ecosystem is to give each agent its own git worktree so file writes can’t collide.
Three things have to be true for parallel agents to stay correct:
- File isolation: each agent writes to its own directory, not a shared one.
- Context isolation: each agent sees its own task, not the orchestrator’s running state.
- Lock hygiene: when an agent dies or times out, its locks release so the next one isn’t blocked forever.
OpenClaw v2026.5.28 tightened all three.
What v2026.5.28 actually changed
The release notes lead with runtime recovery for spawned agents. The concrete fixes (with PR refs from the v2026.5.28 release notes):
| Fix | What it prevents | PR |
|---|---|---|
| Spawned agent cwd/workspace state kept separated | Two agents writing the same file | #87218 |
| Hook context kept prompt-local | One agent’s instructions leaking into another | #86875 |
| Session locks release on timeout abort | A hung agent wedging the runtime | #87399 |
| Live OpenClaw-owned locks survive cleanup | Killing a still-active agent during teardown | #87375 |
| Stale restart continuations avoided | An agent resuming work it already finished | #88129 |
That last pair is subtle and matters. When the runtime cleans up after a timeout, it has to release the abandoned locks without deleting the locks held by agents that are still alive. v2026.5.28 separates those two cases. Cleanup no longer kills a working agent by accident, and a dead agent no longer holds a lock nobody can clear.
How isolation works when you spawn an agent
Here’s the lifecycle, grounded in the runtime behavior the release describes:
- Spawn. The orchestrator hands a subagent a task. The subagent gets its own working directory, not the parent’s, so its file operations are scoped to that path.
- Run. The subagent’s hook context is prompt-local. It sees its task and its tools. The orchestrator’s live state stays with the orchestrator.
- Lock. While the subagent works, it holds a session lock on its own resources. Other agents see that lock and stay out.
- Finish or abort. On clean completion, the lock releases normally. On a timeout abort, the runtime releases that agent’s lock without touching locks held by agents still running.
The practical result: you can fan out five agents from one orchestrator and trust that agent three timing out won’t strand agents one, two, four, and five.
For the mechanics of defining and wiring up a team in the first place, the multi-agent setup guide walks through agents, SOUL files, and channels. This post is about what keeps that team from stepping on itself once it’s running.
Coordinating work without colliding: Workboard and Codex Supervisor
Isolation stops agents from corrupting each other. Coordination is the other half. Agents that are isolated still need a way to hand off work without a shared scratchpad they all scribble on.
v2026.5.28 shipped two pieces here:
- Workboard: agent coordination tools for tracking and handing off active agent work. Instead of agents guessing what the others are doing, there’s a structured place to track and pass tasks.
- Codex Supervisor: a plugin path for delegated Codex workflows, with the supervisor keeping app-server session listing on the loaded state path and bounding stored history scans so a long-running delegation doesn’t balloon.
The pattern mirrors what teams running Claude Code subagents describe: a main agent delegates, subagents execute in isolation, and the orchestrator embeds the context each task needs rather than relying on shared memory. OpenClaw’s version is that the delegation and the isolation are runtime guarantees, not conventions you have to remember to follow.
Isolation vs. coordination: which problem are you solving?
These get conflated, so it’s worth separating them:
| Concern | Question it answers | What handles it |
|---|---|---|
| Isolation | Can agent A clobber agent B’s files or context? | cwd/workspace separation, prompt-local hooks |
| Lock hygiene | Does a dead agent block the live ones? | Session-lock release on timeout abort |
| Coordination | How do agents hand off work cleanly? | Workboard, Codex Supervisor |
If your agents are overwriting files, you have an isolation problem. If your agents stall whenever one of them crashes, you have a lock problem. If your agents redo each other’s work or miss handoffs, you have a coordination problem. v2026.5.28 touches all three, but the fix is different for each.
Putting subagent workspace isolation to work
If you run more than one agent at a time, update to v2026.5.28 or later and let the runtime do the separating. A few habits make it hold up:
- Don’t point two agents at the same directory by hand. The runtime separates spawned agents; don’t override that by configuring a shared path.
- Give each agent a scoped task. Prompt-local context only helps if the task you hand the subagent is self-contained. Embed what it needs.
- Expect timeouts and let them release. A timed-out agent now releases its lock cleanly. Treat a timeout as recoverable, not as a reason to restart the whole stack.
- Use Workboard for handoffs instead of a shared file agents poll.
For a deeper look at how the runtime fits together, see how OpenClaw works, and if you’re scheduling overnight agent runs, the cron jobs guide covers the scheduling side.
FAQ
What is subagent workspace isolation? It’s the runtime guarantee that each agent OpenClaw spawns gets its own working directory and its own prompt-local context, so concurrent agents can’t overwrite each other’s files or leak instructions between tasks.
Does this matter if I only run one agent? No. Isolation only matters when two or more agents run at the same time. A single agent owns its workspace by definition.
What happens when a subagent times out? As of v2026.5.28, a timed-out agent releases its session lock on abort, while locks held by agents that are still running are left intact. The runtime no longer wedges because one agent died.
Is this the same as sandboxing? No. Workspace isolation is about separating working directories and context between agents on the same host. Full sandboxing adds OS-level containment. Isolation prevents agents from colliding; sandboxing constrains what any single agent can reach.
How do isolated agents share work? Through coordination tools (Workboard for tracking and handing off active work, and the Codex Supervisor path for delegated Codex workflows) rather than a shared file or memory all agents write to.
Subagent workspace isolation is the unglamorous plumbing that makes a multi-agent team trustworthy. You notice it only when it’s missing: when a file you expected is gone, or the whole runtime hangs because one agent timed out. v2026.5.28 spent its top fixes making sure you don’t notice it at all.
Sources: