Summary

Describe the problem and fix in 2–5 bullets:

• Problem: The drive letter of the path on Windows does not start with the slash, leading to false error of the sandbox security. So I added the passby branch to avoid it. When launching the gateway with the custom bindings on Windows, the drive letter is recoginzed as a relative path, leading to false error of the sand security.
• Why it matters: This bug affects the usage of the custom binding features on Windows, which causes the custom binding feature to be completely unusable on Windows, as absolute Windows paths (e.g., D:/path) are incorrectly rejected by the security check.
• What changed: Adding the branch of Windows path support to the sandbox security validation.
• What did NOT change (scope boundary): The current permission check and the posix-like path validation are not changed.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related #

User-visible / Behavior Changes

List user-visible changes (including defaults/config).
If none, write None.
The host path on Windows can be binded to the sandbox.

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: Windows 11 26200.7840
• Runtime/container: Local Machine for the host, and Docker Desktop 4.34.3 with WSL2 backend for docker.
• Model/provider: deepseek-V3.2 reasoner
• Integration/channel (if any):
• Relevant config (redacted):

Steps

"agents": {
    "defaults": {
      "sandbox": {
        "mode": "all",
        "scope": "session",
        "workspaceAccess": "ro",
        "docker": {
          "image": "192.168.1.102:8080/library/ubuntu:latest",
          "network": "bridge",
          "binds": ["D:/data/openclaw/src:/src:ro", "D:/data/openclaw/output:/output:rw"]
        }
      }
    }
  },

1. Modify the openclaw.json like the above fragment.
2. Launch the gateway

Expected

• The gateway starts successfully, and the skills are able to executed in the docker container with proper binding.

Actual

• The gateway fails to start.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

before

🦞 OpenClaw 2026.3.8 (3a12cf5) — One CLI to rule them all, and one more restart because you changed the port.

│
◇ Config ───────────────────────────────────────────────────╮
│ │
│ Config invalid; doctor will run with best-effort config. │
│ │
├────────────────────────────────────────────────────────────╯
Config invalid
File: ~.openclaw\openclaw.json
Problem:

• agents.defaults.sandbox.docker.binds.0: Sandbox security: bind mount "D:/data/openclaw/src:/src:ro" uses a non-absolute source path "D". Only absolute POSIX paths are supported for sandbox binds.
• agents.defaults.sandbox.docker.binds.1: Sandbox security: bind mount "D:/data/openclaw/output:/output:rw" uses a non-absolute source path "D". Only absolute POSIX paths are supported for sandbox binds.

Run: openclaw doctor --fix
Gateway aborted: config is invalid.
agents.defaults.sandbox.docker.binds.0: Sandbox security: bind mount "D:/data/openclaw/src:/src:ro" uses a non-absolute source path "D". Only absolute POSIX paths are supported for sandbox binds.
agents.defaults.sandbox.docker.binds.1: Sandbox security: bind mount "D:/data/openclaw/output:/output:rw" uses a non-absolute source path "D". Only absolute POSIX paths are supported for sandbox binds.
Fix the config and retry, or run "openclaw doctor" to repair.

after

🦞 OpenClaw 2026.3.8 (3a12cf5) — We ship features faster than Apple ships calculator updates.

Restarted Scheduled Task: OpenClaw Gateway

Human Verification (required)

What you personally verified (not just CI), and how: I put some files in the src directory, and then launched the gateway and tested the agent with several prompts. The agent successfully obtained these files and read the correct content of the files. Besides, I have checked the container, the src and output directory are correctly binded. The src directory is read-only and the output directory is read-write. The original permission check is not corrupted.

• Verified scenarios: Agent successfully reads files from the read‑only /src directory. Agent writes files to the read‑write /output directory and the files persist on the host. Inside the container, /src is mounted as ro and /output as rw (confirmed via docker inspect). Bind mounts using D:/... syntax are accepted by the security validation and work as expected.
• Edge cases checked:
• What you did not verify: The regression testing of the original posix-like path validation as this patch is only a side-enhancement of the original conditions.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: Directly revert this commit and reinstall.
• Files/config to restore: None
• Known bad symptoms reviewers should watch for: Windows paths of custom bindings will be rejected (if regression occurs)

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.
None