path escapes sandbox

[dull salmon]

Hi @whole copper ! I have a multi-agent workspace where each agent has sibling-level workspaces with one being the "primary" workspace.

My agents are not sandboxed.
They're in YOLO mode.
host=gateway so it's not a NODE issue.
Almost everything else is working great!

These agents keep using Read, Write etc. and getting errors that contain these snippets:

• error [tools] write failed: path alias escape blocked raw_params={
  -Error: Symlink escapes sandbox root

The agents can eventually figure out to use exec but it wastes a lot of tokens.

Is there a way to approve symlinks across workspaces? Or a niche config setting that lets agents use symlinks from their workspace?

Or, is there a better way to organize my agent's workspaces so that they can share some,—but not all—resources in the primary workspace?

openclaw --version: 2026.5.3-1

[potent surge]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[whole copper]

Short version: I don’t see a supported “approve this symlink across workspaces” setting for Read/Write/Edit. Those file tools intentionally canonicalize paths and block symlink/hardlink aliases that escape the tool root. The similar-looking allowSymlinkCommand knob is for provider secret exec command paths, not workspace file tools.

The thing I’d check first in your config is:
openclaw config get tools.fs.workspaceOnly
openclaw config get tools.exec.applyPatch.workspaceOnly

Even with sandbox mode off / YOLO, tools.fs.workspaceOnly: true fences filesystem tools to the agent workspace, and sibling symlinks will trip errors like path alias escape blocked / Symlink escapes sandbox root. Setting it false is all-or-nothing host filesystem access, not selective symlink approval, so I’d only use that if you really want the file tools to be unconstrained.

For the workspace layout: avoid sibling workspace symlinks. Use real descendants of the root each agent is allowed to see. Practical patterns:

• Copy or generate a bounded shared/ folder into each agent workspace when the shared files are safe for that agent.
• Put shared knowledge in skills/memory/docs instead of filesystem symlinks if it’s mostly read-only context.
• If you do enable sandboxing later, use explicit Docker binds like /host/shared:/shared:ro for shared resources; bind validation still resolves symlinks and blocks escapes.

Docs I checked: https://docs.openclaw.ai/concepts/agent-workspace, https://docs.openclaw.ai/concepts/multi-agent, https://docs.openclaw.ai/gateway/sandboxing#custom-bind-mounts, and the FAQ sandboxing section: https://docs.openclaw.ai/help/faq#sandboxing-and-memory

If you’re getting this while tools.fs.workspaceOnly is false and no sandbox is active, that smells like a bug or an unexpected tool wrapper. In that case I’d file an issue with the relevant agent config snippet plus one full tool error: https://github.com/openclaw/openclaw/issues

[dull salmon]

tools.fs.workspaceOnly = true
tools.exec.applyPatch.workspaceOnly = Config path not found

[whole copper]

That explains it. tools.fs.workspaceOnly: true is the fence causing sibling-workspace symlinks to fail for Read/Write/Edit.

tools.exec.applyPatch.workspaceOnly being “Config path not found” just means it’s unset; apply_patch is workspace-contained by default unless explicitly disabled, so that’s expected.

Your options are basically:

• Keep tools.fs.workspaceOnly: true and reorganize shared resources so they are real files/dirs inside each agent workspace, not symlinks to sibling workspaces.
• Set tools.fs.workspaceOnly: false if these are fully trusted YOLO agents and you want file tools to write outside the workspace. That removes the workspace fence broadly; it’s not a per-symlink allowlist.
• Put shared read-only context into a shared skill/docs package and install/copy it into each workspace, which is usually cleaner than filesystem symlink sharing.

Config docs for the workspace model: https://docs.openclaw.ai/concepts/agent-workspace

[dull salmon]

@whole copper thank you! could another option be to make a skill that lets the agents write to specific paths and give each agent access?

[whole copper]

Yes, but with one important distinction: a skill alone won’t bypass Read/Write/Edit path guards. Skills are instructions that teach the agent how to use tools; they don’t add privileged filesystem access by themselves.

The workable version is: create a small plugin tool that writes only to an explicit allowlist of host paths, then ship a skill that teaches agents when/how to call that tool. The plugin is the enforcement boundary; the skill is the UX/instructions layer.

I’d design it narrowly:

• Tool name like shared_resource_write, not generic write_anywhere.
• Plugin config contains named roots, e.g. project_docs, shared_artifacts, each resolving to a canonical absolute path.
• The tool accepts rootId + relative path + content/operation, never arbitrary absolute paths.
• It resolves realpaths/deepest existing parent and rejects .., symlink escapes, hidden credential dirs, and writes outside that named root.
• Gate access per agent with agents.list[].skills for the teaching layer, and tool allow/deny policy for the actual tool if you need stricter separation.

That gives you “specific shared writable areas” without turning off tools.fs.workspaceOnly globally. It’s more work than symlinks, but it matches the security model better.

Docs: skills/per-agent visibility https://docs.openclaw.ai/tools/skills#per-agent-vs-shared-skills, plugin tools https://docs.openclaw.ai/plugins/building-plugins#registering-agent-tools, multi-agent note that tool allowlists are tools not skills https://docs.openclaw.ai/concepts/multi-agent#per-agent-sandbox-and-tool-configuration