#Possible workspace attachment bug, workspaceAccess: none despite configured workspace

1 messages · Page 1 of 1 (latest)

halcyon zealot
#

Hey, I think I may have found a workspace attachment issue on OpenClaw 2026.4.15.

I have agents.defaults.workspace configured to a valid local path, and that host path is writable from the shell, but the agent can’t write to /workspace, including from the Control UI main session.

openclaw sandbox explain shows:

agentId: main
sessionKey: agent:main:main
runtime: direct
mode: non-main
workspaceAccess: none

I also tried openclaw sandbox recreate --agent main, but it didn’t change anything.

severe saffronBOT
tacit wagonBOT
#

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

severe saffronBOT
keen bayBOT
#

I think this is more likely sandbox semantics than a broken workspace attach.

A few important bits:

  • openclaw sandbox explain with no --session explains the agent’s main session.
    So agent:main:main + runtime: direct is expected when sandbox.mode: "non-main".

  • In direct mode, the agent uses your real agents.defaults.workspace path as cwd.
    So from the Control UI main session, writing to /workspace/... is the wrong test. Use a relative path like test.txt, or the actual host path from agents.defaults.workspace.

  • In sandboxed non-main sessions with workspaceAccess: "none", /workspace is the sandbox scratch workspace, not your configured host workspace.

  • Only workspaceAccess: "rw" makes /workspace map to the agent’s configured host workspace.

So the behavior matrix is basically:

  • mode: "non-main" + main session → runtime: direct, host workspace, no special /workspace mount
#
  • mode: "non-main" + Discord/thread session → sandboxed
  • workspaceAccess: "none" → sandbox writes go to sandbox workspace
  • workspaceAccess: "rw" → sandbox writes go to host workspace at /workspace

That also explains why openclaw sandbox recreate --agent main didn’t change this. It recreates sandbox runtimes, but it does not change mode / workspaceAccess behavior.

Docs:

If you want, paste these next and I can tell you which case you’re in:

openclaw --version
openclaw config get agents.defaults.workspace