Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

This looks like a regression, or at least an incomplete recurrence, of [#9348](https://github.com/
/issues/9348).

In my current setup, a custom sandbox Docker bind mount is definitely present in the live agent
container, and exec inside the container can access it, but file tools still reject the same
path with sandbox path errors.

So the core mismatch from #9348 still appears to exist:

• Docker/container access works
• exec can see the mounted path
• file tools (read, and likely related path-guarded file operations) still reject it

Steps to reproduce

Repro Steps

1. Configure an agent with sandbox Docker binds:

   {
     "workspace": "/Users/me/agent-workspace",
     "sandbox": {
       "mode": "all",
       "workspaceAccess": "rw",
       "scope": "agent",
       "docker": {
         "dangerouslyAllowExternalBindSources": true,
         "binds": [
           "/Users/me/ExternalDocs:/external-docs:rw"
         ]
       }
     }
   }
   

2. Restart the gateway.

3. Remove any existing sandbox runtime for that agent so it must be recreated.

4. Send the agent a fresh message so a new sandbox container is created.

5. Verify the live container really has the bind:

   docker inspect --format '{{json .HostConfig.Binds}}'

   Expected:

   ["/Users/me/agent-workspace:/workspace:z", "/Users/me/ExternalDocs:/external-docs:rw"]

6. From the agent, run:

   • read("/external-docs")
   • read("/external-docs/some-file.md")

7. Also from the agent, run:

   • exec: ls -la /external-docs

Expected behavior

Expected behavior

If a path is mounted via sandbox.docker.binds into the live sandbox container, file tools should
treat that mount as allowed and be able to read it.

At minimum, read("/skyvault") should not fail with Sandbox path escapes allowed mounts when /
skyvault is an actual configured bind mount in the running container.

Why this looks like a regression of #9348

Issue #9348 (#9348) described the same architectural mismatch:

• Docker bind exists
• exec can use it
• file tools still enforce narrower sandbox-root restrictions

This report reproduces that same mismatch on 2026.4.15, with read failing even though the bound
path exists inside the live container.

Important evidence

This is not a stale-container or config parsing issue anymore.

I verified all of the following:

1. The config on disk contains:

   "/Users/skylarpayne/skyvault:/skyvault:rw"

2. The old stale/orphaned container was removed.

3. The newly recreated Palmer container has:

   ["/Users/skylarpayne/chiefs/palmer-workspace:/workspace:z",
   "/Users/skylarpayne/skyvault:/skyvault:rw"]

4. Inside the live recreated container:

   • /skyvault exists
   • /Users/skylarpayne/skyvault does not

5. File tools still reject /skyvault.

That seems to rule out:

• bad config
• stale bind target
• container not recreated
• Docker bind creation failure

Actual behavior

• read("/external-docs") fails with a sandbox path / allowed mounts error
• exec: ls -la /external-docs succeeds

OpenClaw version

2026.4.15

Operating system

macOS Tahoe 26.2

Install method

npm

Model

codex/gpt-5.4

Provider / routing chain

openclaw -> openai

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response