Bug type

Behavior bug (incorrect output/state without crash)

Summary

In Docker-based non-main sandbox sessions, OpenClaw exposes host-style skill paths in the prompt (for example ~/.openclaw/skills/<skill>/SKILL.md), but file access is enforced relative to the sandbox workspace.

This causes read to fail with Path escapes sandbox root, even though the skill has already been synced into the sandbox under skills/<skill>/SKILL.md.

Steps to reproduce

1. Install a managed/custom skill under ~/.openclaw/skills/<skill>/SKILL.md
2. Start a non-main sandboxed session that should trigger that skill
3. Check the session log

Expected behavior

In sandboxed sessions, skill paths exposed to the model should resolve inside the sandbox, for example:

• skills/<skill>/SKILL.md
• /workspace/skills/<skill>/SKILL.md

The model should not be told to read a host-only path that is outside the sandbox root.

Actual behavior

The model tries to read:

{
  "name": "read",
  "arguments": {
    "path": "~/.openclaw/skills/<skill>/SKILL.md"
  }
}

The tool fails with:

{
  "status": "error",
  "tool": "read",
  "error": "Path escapes sandbox root (...): /home/node/.openclaw/skills/<skill>/SKILL.md"
}

But the sandbox already contains a synced copy at:

/workspace/skills/<skill>/SKILL.md

Suspected area

• src/agents/skills/workspace.ts
• src/agents/sandbox-paths.ts
• src/agents/sandbox/fs-paths.ts

This looks like a mismatch between skill prompt path generation and sandbox file path resolution.

OpenClaw version

2026.3.8

Operating system

Ubuntu22.04

Install method

Docker version 28.4.0, build d8eb465

Model

GPT-5.4

Provider / routing chain

OpenClaw gateway -> main agent -> non-main Docker sandbox session -> gpt-5.4

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

### Logs and evidence

The sandboxed session attempted to read the skill from a host-style path:


{
  "type": "toolCall",
  "name": "read",
  "arguments": {
    "path": "~/.openclaw/skills/<skill>/SKILL.md"
  }
}


The read failed because the path was outside the sandbox root:


{
  "type": "toolResult",
  "toolName": "read",
  "details": {
    "status": "error",
    "tool": "read",
    "error": "Path escapes sandbox root (~/.openclaw/sandboxes/<sandbox-session>): /home/node/.openclaw/skills/<skill>/SKILL.md"
  }
}


The affected session was a sandboxed non-main run:


Runtime: docker/non-main


The same skill already existed inside the sandbox workspace:


/workspace/skills/<skill>/SKILL.md


Host-side synced sandbox copy:


.../sandboxes/<sandbox-session>/skills/<skill>/SKILL.md


Later tool calls in the same session also failed with:


Error response from daemon: container <container-id> is not running


All IDs, skill names, container IDs, and session identifiers above are sanitized placeholders.

Impact and severity

No response

Additional information

Environment

• OpenClaw 2026.3.8
• Docker Compose deployment
• Docker sandbox enabled
• agents.defaults.sandbox.mode = "non-main"
• agents.defaults.sandbox.scope = "session"
• agents.defaults.sandbox.workspaceAccess = "none"