🔒 Aisle Security Analysis

We found 2 potential security issue(s) in this PR:

1. 🟠 workspaceAccess="none" can be bypassed via sessions_spawn inheriting real workspace path

Description

When a session is sandboxed with workspaceAccess: "none", the intent is to prevent exposing the real host workspace directory to the agent. However, the new spawnWorkspaceDir behavior passes the real workspace path (resolvedWorkspace) into tool creation whenever workspaceAccess !== "rw" (i.e., for both ro and none).

This value is then fed into sessions_spawn as its workspaceDir context, which becomes the spawned run's workspaceDir override. A spawned child targeting an agent/runtime configured with workspaceAccess: "ro" or "rw" can therefore receive a sandbox mount of the real workspace path, bypassing the parent session’s workspaceAccess: "none" restriction.

Vulnerable flow:

• Parent run in sandbox with workspaceAccess: "none" sets spawnWorkspaceDir to the real workspace
• openclaw-tools passes that as workspaceDir to createSessionsSpawnTool
• sessions_spawn forwards workspaceDir into spawnSubagentDirect context
• spawnSubagentDirect writes it into spawned run metadata (workspaceDir), which the gateway accepts as an internal-only workspace override for spawned runs
• Child run starts with params.workspaceDir set to that real path; if the child’s sandbox policy is ro/rw, the real workspace gets mounted/readable (and writable for rw)

This is a privilege escalation / access-control bypass of the workspaceAccess: "none" confinement model.

Vulnerable code:

​// attempt.ts
spawnWorkspaceDir:
  sandbox?.enabled && sandbox.workspaceAccess !== "rw" ? resolvedWorkspace : undefined,

​// openclaw-tools.ts
createSessionsSpawnTool({
  ...,
  workspaceDir: spawnWorkspaceDir,
})

Recommendation

Treat workspaceAccess: "none" as non-inheritable for workspace paths.

Minimal fix (recommended): only pass spawnWorkspaceDir when workspaceAccess === "ro" (not none). That preserves the intended none isolation while keeping the ro correctness improvement.

​// src/agents/pi-embedded-runner/run/attempt.ts
spawnWorkspaceDir:
  sandbox?.enabled && sandbox.workspaceAccess === "ro" ? resolvedWorkspace : undefined,

Defense-in-depth: also enforce this at the spawn layer (e.g., in createSessionsSpawnTool or spawnSubagentDirect) by ignoring/clearing ctx.workspaceDir when the requester session is sandboxed with workspaceAccess: "none", so callers cannot bypass by other entry points.

2. 🟠 Sandbox workspace isolation bypass via spawnWorkspaceDir in sessions_spawn inheritance

Description

When a parent agent run is sandboxed with a copied workspace (workspaceAccess ro/none), the new spawnWorkspaceDir plumbing causes sessions_spawn to pass the real configured workspace path to spawned subagents.

This weakens the sandbox boundary that previously kept subagents operating only on the parent’s sandbox copy:

• runEmbeddedAttempt sets spawnWorkspaceDir to resolvedWorkspace (real workspace) whenever sandbox.workspaceAccess !== "rw".
• createOpenClawTools resolves spawnWorkspaceDir and uses it as the workspaceDir passed into createSessionsSpawnTool.
• sessions_spawn calls spawnSubagentDirect with ctx.workspaceDir coming from that value; spawnSubagentDirect uses it as an explicit workspace override for the child run metadata.
• The child run then resolves its sandbox context using that workspace path as its agent workspace:
  • If the spawned agent’s sandbox config has workspaceAccess: "ro", /agent becomes a bind mount of the real workspace (read-only) → information disclosure beyond the parent’s sandbox copy.
  • If the spawned agent’s sandbox config has workspaceAccess: "rw" (e.g., a different allowed agentId), /workspace becomes a writable bind mount of the real workspace → privilege escalation / write access despite the parent being confined to a copied workspace.

This is practical whenever the parent is sandboxed and allowed to choose a different agentId via sessions_spawn (controlled by agents.list[*].subagents.allowAgents). Prior to this change, the child inherited the parent’s sandbox copy path, which prevented escalation to the real workspace even when the target agent had a more permissive workspaceAccess.

Recommendation

Treat the parent sandbox’s effective workspace and workspaceAccess as the maximum privilege that spawned subagents may receive.

Concrete options:

1. Do not override sessions_spawn workspaceDir from a sandboxed copied workspace (keep inheriting the sandbox copy):

​// openclaw-tools.ts
createSessionsSpawnTool({
  ...,
  ​// Keep subagents inside the same effective workspace boundary
  workspaceDir,
});

2. If you need subagents to know the real workspace path for UX, pass it as a non-authoritative hint (not used for mounts/FS resolution), or add a separate field (e.g. agentWorkspaceDirHint) that is never used to mount/resolve filesystem access.

3. Add an enforcement check in the spawn path so that sandboxed requesters cannot spawn children with broader workspace access (e.g., prevent spawning an agentId whose sandbox workspaceAccess is less restrictive than the requester’s).

Analyzed PR: #40757 at commit 0e8b27b

_{Last updated on: 2026-03-10T08:41:39Z}

Greptile Summary

This PR fixes a regression introduced in v2026.3.7 where subagents spawned by a session running inside a read-only sandbox would incorrectly inherit the sandboxed workspace directory instead of the real configured workspace path. The fix introduces a spawnWorkspaceDir field threaded through createOpenClawCodingTools → createOpenClawTools → createSessionsSpawnTool, while leaving file tool isolation intact via effectiveWorkspace.

Key changes:

• attempt.ts: Sets spawnWorkspaceDir = resolvedWorkspace when sandbox.workspaceAccess !== "rw", exactly mirroring the condition under which effectiveWorkspace diverges from resolvedWorkspace
• pi-tools.ts / openclaw-tools.ts: New spawnWorkspaceDir option with proper JSDoc, resolved and forwarded through the tool creation chain; falls back to workspaceDir when unset, preserving existing behavior for rw or no-sandbox sessions
• No changes to how file tools consume workspaceDir — sandbox isolation is preserved for the running session; only the workspace inherited by spawned subagents is corrected

Confidence Score: 5/5

• This PR is safe to merge — it is a narrowly scoped, well-reasoned bug fix with no behavior change for non-sandbox or rw-sandbox sessions.
• The condition used for spawnWorkspaceDir in attempt.ts exactly mirrors the existing effectiveWorkspace branching, so it activates precisely when and only when the sandbox copy diverges from the real workspace. resolveWorkspaceRoot is idempotent on absolute paths, so the double-resolution across pi-tools.ts and openclaw-tools.ts is harmless. The fallback to workspaceDir when spawnWorkspaceDir is unset preserves all existing behavior. No other spawn paths were missed — the only subagent workspace inheritance goes through createSessionsSpawnTool via this chain.
• No files require special attention.

_{Last reviewed commit: dcbc2a9}

Merged via squash.

• Prepared head SHA: 0e8b27bf80e41fcce77db8298ac74205c7b3b2c3
• Merge commit: 3495563cfe89ab36e72d022ed4e3678c453c0b1e

Thanks @dsantoreis!