Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

When agents.defaults.sandbox.workspaceAccess is set to "rw", OpenClaw correctly mounts the live agent workspace (~/.openclaw/workspace) into the sandbox Docker container at /workspace. However, the host-side gateway read proxy continues resolving file paths against the per-container snapshot directory (~/.openclaw/sandboxes/<container-id>/) rather than the live workspace.

The snapshot in sandboxes/ is created once when the container is first provisioned and never updated. As the agent writes to /workspace inside the container, the sandboxes/<container-id>/ dir on the host falls progressively out of sync. All subsequent read tool calls from sandboxed sessions resolve against the stale snapshot, silently returning outdated content.

workspaceAccess has zero effect on workspaceRoot

openclaw sandbox explain run back-to-back with none then rw — the only difference in the entire output is the workspaceAccess label. workspaceRoot is identical:

workspaceAccess: none  workspaceRoot: /home/randomman86/.openclaw/sandboxes
workspaceAccess: rw    workspaceRoot: /home/randomman86/.openclaw/sandboxes

The setting changes the Docker bind mount correctly — docker inspect confirms /home/randomman86/.openclaw/workspace → /workspace with workspaceAccess: rw — but the host-side read proxy is never updated to match. The proxy always resolves against ~/.openclaw/sandboxes regardless of workspaceAccess.

Steps to reproduce

1. Set agents.defaults.sandbox.mode: all and agents.defaults.sandbox.workspaceAccess: rw
2. Start the gateway — openclaw provisions a container and seeds ~/.openclaw/sandboxes/<container-id>/ from the workspace at that moment
3. From inside the sandboxed session (e.g. via Discord), have the agent write any file to /workspace/ (e.g. update HEARTBEAT.md, SOUL.md, or MEMORY.md)
4. From the same or a new sandboxed session, call read on that file
5. Observe: the read tool returns the stale snapshot content from sandboxes/<container-id>/, not the updated content

To confirm the mismatch, run openclaw sandbox explain — workspaceRoot will show ~/.openclaw/sandboxes even with workspaceAccess: rw.

Expected behavior

With workspaceAccess: "rw", the gateway read proxy should resolve paths against the live agent workspace (~/.openclaw/workspace), consistent with the Docker bind mount. The workspaceRoot reported by sandbox explain should reflect the live workspace path, not the sandboxes/ snapshot path.

Actual behavior

workspaceRoot is hardcoded to ~/.openclaw/sandboxes regardless of workspaceAccess. The Docker mount is correct; the host-side proxy is not. The two halves of the sandbox point at different directories.

read AGENTS.md and read HEARTBEAT.md from a sandboxed Discord session returned March 29 snapshot versions. Live versions (with significant content added since) were only accessible inside the container at /workspace/. Same stale-read behavior persisted across gateway restarts and an upgrade from 2026.3.24 to 2026.4.9.

OpenClaw version

2026.3.24

Operating system

Ubuntu host (native, not DOOD)

Install method

npm global

Model

gemini flash 2.5

Provider / routing chain

openclaw -> openrouter -> gemini flash 2.5

Additional provider/model setup details

• OpenClaw version: 2026.3.24 (when first observed), confirmed present in 2026.4.9
• Runtime: gateway on Ubuntu host (native, not DOOD)
• Sandbox mode: agents.defaults.sandbox.mode: all
• workspaceAccess: rw
• Node: v22.22.0

Workaround: Replace ~/.openclaw/sandboxes/<container-id>/ with a symlink to ~/.openclaw/workspace/:

mv ~/.openclaw/sandboxes/agent-main-<id> ~/.openclaw/sandboxes/agent-main-<id>.bak
ln -s ~/.openclaw/workspace ~/.openclaw/sandboxes/agent-main-<id>

Not persistent — must be reapplied if the container is recreated.

Related issues:

• [Bug]: Sandbox system prompt injects host-side workspace path instead of container path #16790 (closed) — same family: workspaceAccess: rw not updating host-side path resolution in the system prompt layer; fixed Feb 2026 but read proxy layer was not addressed
• Sandbox path validation fails for container-internal paths (/workspace/...) #9560 (closed) — container-internal path validation mismatch; fixed but a different layer
• sandbox: keep workspaceAccess none workspaces writable #37634 (closed) — workspaceAccess: none workspace mounted read-only

Logs, screenshots, and evidence

Impact and severity

• Affected: all users with sandbox.mode: all or non-main and workspaceAccess: rw
• Severity: High — agent silently reads stale file content with no error, making workspace files appear unchanged after any write operation from within the sandbox
• Frequency: 100% reproducible — every read tool call from a sandboxed session hits the stale proxy path
• Persists across: gateway restarts, openclaw upgrades (confirmed 2026.3.24 → 2026.4.9)

Additional information

Last known good: 2026.3.24 with sandbox.mode=non-main (workspaceAccess=rw, proxy not used). First confirmed bad: 2026.3.24 with sandbox.mode=all. Confirmed still present in 2026.4.9.