Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

OpenClaw สามารถเรียกใช้ เครื่องมือภายในแบ็กเอนด์ sandbox เพื่อลดขอบเขตผลกระทบได้ สิ่งนี้เป็น ตัวเลือก และควบคุมด้วยการกำหนดค่า (agents.defaults.sandbox หรือ agents.list[].sandbox) หากปิด sandboxing เครื่องมือจะทำงานบนโฮสต์ Gateway จะยังอยู่บนโฮสต์ ส่วนการเรียกใช้เครื่องมือจะทำงานใน sandbox ที่แยกออกมาเมื่อเปิดใช้งาน
นี่ไม่ใช่ขอบเขตความปลอดภัยที่สมบูรณ์แบบ แต่ช่วยจำกัดการเข้าถึงระบบไฟล์และโพรเซสได้อย่างมีนัยสำคัญเมื่อโมเดลทำสิ่งที่ไม่สมเหตุสมผล

สิ่งที่จะถูก sandbox

  • การเรียกใช้เครื่องมือ (exec, read, write, edit, apply_patch, process ฯลฯ)
  • เบราว์เซอร์ใน sandbox ที่เป็นตัวเลือก (agents.defaults.sandbox.browser)
  • โดยค่าเริ่มต้น เบราว์เซอร์ใน sandbox จะเริ่มทำงานอัตโนมัติ (ทำให้แน่ใจว่า CDP เข้าถึงได้) เมื่อเครื่องมือเบราว์เซอร์ต้องใช้ กำหนดค่าได้ผ่าน agents.defaults.sandbox.browser.autoStart และ agents.defaults.sandbox.browser.autoStartTimeoutMs
  • โดยค่าเริ่มต้น คอนเทนเนอร์เบราว์เซอร์ใน sandbox จะใช้เครือข่าย Docker เฉพาะ (openclaw-sandbox-browser) แทนเครือข่าย bridge ส่วนกลาง กำหนดค่าได้ด้วย agents.defaults.sandbox.browser.network
  • agents.defaults.sandbox.browser.cdpSourceRange ที่เป็นตัวเลือกจำกัดการรับทราฟฟิก CDP ที่ขอบคอนเทนเนอร์ด้วยรายการอนุญาต CIDR (ตัวอย่างเช่น 172.21.0.1/32)
  • การเข้าถึง noVNC สำหรับผู้สังเกตการณ์มีการป้องกันด้วยรหัสผ่านโดยค่าเริ่มต้น OpenClaw จะส่ง URL โทเคนอายุสั้นที่ให้บริการหน้าบูตสแตรปภายในเครื่อง และเปิด noVNC พร้อมรหัสผ่านใน URL fragment (ไม่ใช่ใน query/header logs)
  • agents.defaults.sandbox.browser.allowHostControl อนุญาตให้เซสชันใน sandbox กำหนดเป้าหมายไปยังเบราว์เซอร์ของโฮสต์อย่างชัดเจน
  • รายการอนุญาตที่เป็นตัวเลือกจะควบคุม target: "custom": allowedControlUrls, allowedControlHosts, allowedControlPorts
ไม่ได้ถูก sandbox:
  • โพรเซส Gateway เอง
  • เครื่องมือใดก็ตามที่อนุญาตอย่างชัดเจนให้ทำงานนอก sandbox (เช่น tools.elevated)
    • Elevated exec จะข้าม sandboxing และใช้เส้นทาง escape ที่กำหนดค่าไว้ (gateway โดยค่าเริ่มต้น หรือ node เมื่อเป้าหมาย exec คือ node)
    • หากปิด sandboxing อยู่ tools.elevated จะไม่เปลี่ยนแปลงการเรียกใช้ (อยู่บนโฮสต์อยู่แล้ว) ดู โหมด Elevated

โหมด

agents.defaults.sandbox.mode ควบคุมว่าจะใช้ sandboxing เมื่อใด:
ไม่มี sandboxing

ขอบเขต

agents.defaults.sandbox.scope ควบคุมว่าจะสร้าง คอนเทนเนอร์กี่ตัว:
  • "agent" (ค่าเริ่มต้น): หนึ่งคอนเทนเนอร์ต่อ agent
  • "session": หนึ่งคอนเทนเนอร์ต่อเซสชัน
  • "shared": หนึ่งคอนเทนเนอร์ที่แชร์โดยทุกเซสชันที่ถูก sandbox

แบ็กเอนด์

agents.defaults.sandbox.backend ควบคุมว่า runtime ใด ให้บริการ sandbox:
  • "docker" (ค่าเริ่มต้นเมื่อเปิดใช้งาน sandboxing): runtime sandbox ที่รองรับด้วย Docker ภายในเครื่อง
  • "ssh": runtime sandbox ระยะไกลทั่วไปที่รองรับด้วย SSH
  • "openshell": runtime sandbox ที่รองรับด้วย OpenShell
การกำหนดค่าเฉพาะ SSH อยู่ใต้ agents.defaults.sandbox.ssh การกำหนดค่าเฉพาะ OpenShell อยู่ใต้ plugins.entries.openshell.config

การเลือกแบ็กเอนด์

DockerSSHOpenShell
ตำแหน่งที่ทำงานคอนเทนเนอร์ภายในเครื่องโฮสต์ใดก็ได้ที่เข้าถึงได้ผ่าน SSHsandbox ที่จัดการโดย OpenShell
การตั้งค่าscripts/sandbox-setup.shคีย์ SSH + โฮสต์เป้าหมายเปิดใช้งาน Plugin OpenShell
โมเดล workspaceBind-mount หรือ copyRemote-canonical (seed ครั้งเดียว)mirror หรือ remote
การควบคุมเครือข่ายdocker.network (ค่าเริ่มต้น: none)ขึ้นอยู่กับโฮสต์ระยะไกลขึ้นอยู่กับ OpenShell
เบราว์เซอร์ sandboxรองรับไม่รองรับยังไม่รองรับ
Bind mountsdocker.bindsN/AN/A
เหมาะที่สุดสำหรับการพัฒนาภายในเครื่อง, การแยกแบบเต็มการถ่ายงานไปยังเครื่องระยะไกลsandbox ระยะไกลที่มีการจัดการพร้อมการซิงก์สองทางที่เป็นตัวเลือก

แบ็กเอนด์ Docker

sandboxing ปิดอยู่โดยค่าเริ่มต้น หากคุณเปิดใช้งาน sandboxing และไม่ได้เลือกแบ็กเอนด์ OpenClaw จะใช้แบ็กเอนด์ Docker ซึ่งเรียกใช้เครื่องมือและเบราว์เซอร์ sandbox ภายในเครื่องผ่านซ็อกเก็ต Docker daemon (/var/run/docker.sock) การแยกคอนเทนเนอร์ sandbox ถูกกำหนดโดย Docker namespaces หากต้องการเปิดเผย GPU ของโฮสต์ให้ sandbox ของ Docker ตั้งค่า agents.defaults.sandbox.docker.gpus หรือ override ราย agent agents.list[].sandbox.docker.gpus ค่านี้จะถูกส่งให้แฟล็ก --gpus ของ Docker เป็นอาร์กิวเมนต์แยกต่างหาก ตัวอย่างเช่น "all" หรือ "device=GPU-uuid" และต้องใช้ runtime ของโฮสต์ที่เข้ากันได้ เช่น NVIDIA Container Toolkit
ข้อจำกัด Docker-out-of-Docker (DooD)หากคุณปรับใช้ OpenClaw Gateway เองเป็นคอนเทนเนอร์ Docker มันจะจัดการคอนเทนเนอร์ sandbox แบบ sibling โดยใช้ซ็อกเก็ต Docker ของโฮสต์ ซึ่งทำให้เกิดข้อจำกัดด้านการแมปพาธเฉพาะดังนี้:
  • การกำหนดค่าต้องใช้พาธของโฮสต์: การกำหนดค่า workspace ใน openclaw.json ต้องมี พาธสัมบูรณ์ของโฮสต์ (เช่น /home/user/.openclaw/workspaces) ไม่ใช่พาธภายในคอนเทนเนอร์ Gateway เมื่อ OpenClaw ขอให้ Docker daemon สร้าง sandbox daemon จะประเมินพาธโดยอิง namespace ของ Host OS ไม่ใช่ namespace ของ Gateway
  • ความเท่าเทียมของ FS bridge (volume map ที่เหมือนกัน): โพรเซส native ของ OpenClaw Gateway ยังเขียนไฟล์ Heartbeat และ bridge ไปยังไดเรกทอรี workspace ด้วย เนื่องจาก Gateway ประเมินสตริงเดียวกันทุกประการ (พาธของโฮสต์) จากภายในสภาพแวดล้อมคอนเทนเนอร์ของตัวเอง การปรับใช้ Gateway ต้องมี volume map ที่เหมือนกันซึ่งเชื่อม namespace ของโฮสต์แบบ native (-v /home/user/.openclaw:/home/user/.openclaw)
  • โหมดโค้ด Codex: เมื่อ sandbox ของ OpenClaw เปิดใช้งานอยู่ OpenClaw จะจำกัดเทิร์น app-server ของ Codex ให้ใช้ sandboxing workspace-write ของ Codex แม้ว่าค่าเริ่มต้นของ Plugin Codex จะเป็น danger-full-access ก็ตาม อย่า mount ซ็อกเก็ต Docker ของโฮสต์เข้าไปในคอนเทนเนอร์ sandbox ของ agent หรือ sandbox Codex แบบกำหนดเอง
หากคุณแมปพาธภายในโดยไม่มีความเท่าเทียมกับโฮสต์แบบสัมบูรณ์ OpenClaw จะโยนข้อผิดพลาดสิทธิ์ EACCES แบบ native เมื่อพยายามเขียน Heartbeat ภายในสภาพแวดล้อมคอนเทนเนอร์ เพราะสตริงพาธแบบเต็มไม่มีอยู่แบบ native

แบ็กเอนด์ SSH

ใช้ backend: "ssh" เมื่อคุณต้องการให้ OpenClaw sandbox exec, เครื่องมือไฟล์ และการอ่านสื่อบนเครื่องใดก็ได้ที่เข้าถึงได้ผ่าน SSH
{
  agents: {
    defaults: {
      sandbox: {
        mode: "all",
        backend: "ssh",
        scope: "session",
        workspaceAccess: "rw",
        ssh: {
          target: "user@gateway-host:22",
          workspaceRoot: "/tmp/openclaw-sandboxes",
          strictHostKeyChecking: true,
          updateHostKeys: true,
          identityFile: "~/.ssh/id_ed25519",
          certificateFile: "~/.ssh/id_ed25519-cert.pub",
          knownHostsFile: "~/.ssh/known_hosts",
          // Or use SecretRefs / inline contents instead of local files:
          // identityData: { source: "env", provider: "default", id: "SSH_IDENTITY" },
          // certificateData: { source: "env", provider: "default", id: "SSH_CERTIFICATE" },
          // knownHostsData: { source: "env", provider: "default", id: "SSH_KNOWN_HOSTS" },
        },
      },
    },
  },
}
  • OpenClaw สร้าง root ระยะไกลต่อขอบเขตภายใต้ sandbox.ssh.workspaceRoot
  • เมื่อใช้ครั้งแรกหลังจากสร้างหรือสร้างใหม่ OpenClaw จะ seed workspace ระยะไกลนั้นจาก workspace ภายในเครื่องหนึ่งครั้ง
  • หลังจากนั้น exec, read, write, edit, apply_patch, การอ่านสื่อของ prompt และการ staging สื่อขาเข้า จะทำงานกับ workspace ระยะไกลโดยตรงผ่าน SSH
  • OpenClaw ไม่ซิงก์การเปลี่ยนแปลงระยะไกลกลับไปยัง workspace ภายในเครื่องโดยอัตโนมัติ
  • identityFile, certificateFile, knownHostsFile: ใช้ไฟล์ภายในเครื่องที่มีอยู่และส่งผ่านการกำหนดค่า OpenSSH
  • identityData, certificateData, knownHostsData: ใช้สตริงแบบ inline หรือ SecretRefs OpenClaw จะแก้ค่าเหล่านี้ผ่าน snapshot runtime ของ secrets ตามปกติ เขียนลงไฟล์ temp ด้วย 0600 และลบเมื่อเซสชัน SSH จบลง
  • หากตั้งค่าทั้ง *File และ *Data สำหรับรายการเดียวกัน *Data จะชนะสำหรับเซสชัน SSH นั้น
นี่คือโมเดล remote-canonical workspace SSH ระยะไกลจะกลายเป็นสถานะ sandbox จริงหลังจาก seed เริ่มต้น
  • การแก้ไขภายในเครื่องของโฮสต์ที่ทำภายนอก OpenClaw หลังขั้นตอน seed จะมองไม่เห็นจากระยะไกลจนกว่าคุณจะสร้าง sandbox ใหม่
  • openclaw sandbox recreate จะลบ root ระยะไกลต่อขอบเขตและ seed อีกครั้งจากภายในเครื่องเมื่อใช้ครั้งถัดไป
  • เบราว์เซอร์ sandboxing ไม่รองรับบนแบ็กเอนด์ SSH
  • การตั้งค่า sandbox.docker.* ไม่มีผลกับแบ็กเอนด์ SSH

แบ็กเอนด์ OpenShell

ใช้ backend: "openshell" เมื่อคุณต้องการให้ OpenClaw sandbox เครื่องมือในสภาพแวดล้อมระยะไกลที่จัดการโดย OpenShell สำหรับคู่มือการตั้งค่าฉบับเต็ม ข้อมูลอ้างอิงการกำหนดค่า และการเปรียบเทียบโหมด workspace โปรดดู หน้า OpenShell เฉพาะ OpenShell ใช้ transport SSH หลักและ bridge ระบบไฟล์ระยะไกลเดียวกันกับแบ็กเอนด์ SSH ทั่วไป และเพิ่ม lifecycle เฉพาะ OpenShell (sandbox create/get/delete, sandbox ssh-config) พร้อมโหมด workspace mirror ที่เป็นตัวเลือก
{
  agents: {
    defaults: {
      sandbox: {
        mode: "all",
        backend: "openshell",
        scope: "session",
        workspaceAccess: "rw",
      },
    },
  },
  plugins: {
    entries: {
      openshell: {
        enabled: true,
        config: {
          from: "openclaw",
          mode: "remote", // mirror | remote
          remoteWorkspaceDir: "/sandbox",
          remoteAgentWorkspaceDir: "/agent",
        },
      },
    },
  },
}
โหมด OpenShell:
  • mirror (ค่าเริ่มต้น): workspace ภายในเครื่องยังคงเป็น canonical OpenClaw จะซิงก์ไฟล์ภายในเครื่องเข้า OpenShell ก่อน exec และซิงก์ workspace ระยะไกลกลับหลัง exec
  • remote: workspace ของ OpenShell เป็น canonical หลังจากสร้าง sandbox แล้ว OpenClaw จะ seed workspace ระยะไกลหนึ่งครั้งจาก workspace ภายในเครื่อง จากนั้นเครื่องมือไฟล์และ exec จะทำงานกับ sandbox ระยะไกลโดยตรงโดยไม่ซิงก์การเปลี่ยนแปลงกลับ
  • OpenClaw ขอการกำหนดค่า SSH เฉพาะ sandbox จาก OpenShell ผ่าน openshell sandbox ssh-config <name>
  • Core เขียนการกำหนดค่า SSH นั้นลงไฟล์ temp เปิดเซสชัน SSH และใช้ bridge ระบบไฟล์ระยะไกลเดียวกันกับที่ใช้โดย backend: "ssh"
  • ในโหมด mirror มีเพียง lifecycle เท่านั้นที่ต่างออกไป: ซิงก์จากภายในเครื่องไปยังระยะไกลก่อน exec แล้วซิงก์กลับหลัง exec
  • ยังไม่รองรับเบราว์เซอร์ sandbox
  • sandbox.docker.binds ไม่รองรับบนแบ็กเอนด์ OpenShell
  • knob runtime เฉพาะ Docker ภายใต้ sandbox.docker.* ยังคงมีผลเฉพาะกับแบ็กเอนด์ Docker เท่านั้น

โหมด workspace

OpenShell มีโมเดล workspace สองแบบ นี่คือส่วนที่สำคัญที่สุดในทางปฏิบัติ
ใช้ plugins.entries.openshell.config.mode: "mirror" เมื่อคุณต้องการให้ workspace ภายในเครื่องยังคงเป็น canonicalพฤติกรรม:
  • ก่อน exec OpenClaw จะซิงก์พื้นที่ทำงานภายในเครื่องเข้าไปใน OpenShell sandbox
  • หลัง exec OpenClaw จะซิงก์พื้นที่ทำงานระยะไกลกลับมายังพื้นที่ทำงานภายในเครื่อง
  • เครื่องมือไฟล์ยังคงทำงานผ่าน sandbox bridge แต่พื้นที่ทำงานภายในเครื่องยังเป็นแหล่งข้อมูลหลักระหว่างเทิร์น
ใช้สิ่งนี้เมื่อ:
  • คุณแก้ไขไฟล์ภายในเครื่องนอก OpenClaw และต้องการให้การเปลี่ยนแปลงเหล่านั้นปรากฏใน sandbox โดยอัตโนมัติ
  • คุณต้องการให้ OpenShell sandbox ทำงานคล้ายกับ Docker backend มากที่สุดเท่าที่เป็นไปได้
  • คุณต้องการให้พื้นที่ทำงานของโฮสต์สะท้อนการเขียนใน sandbox หลังแต่ละเทิร์น exec
ข้อแลกเปลี่ยน: มีต้นทุนการซิงก์เพิ่มเติมก่อนและหลัง exec
เลือก mirror หากคุณมอง sandbox เป็นสภาพแวดล้อมสำหรับการรันงานชั่วคราว เลือก remote หากคุณมอง sandbox เป็นพื้นที่ทำงานจริง

วงจรชีวิต OpenShell

OpenShell sandbox ยังคงถูกจัดการผ่านวงจรชีวิต sandbox ตามปกติ:
  • openclaw sandbox list แสดง OpenShell runtime รวมถึง Docker runtime
  • openclaw sandbox recreate ลบ runtime ปัจจุบันและให้ OpenClaw สร้างใหม่เมื่อใช้งานครั้งถัดไป
  • ตรรกะ prune ก็รับรู้ backend เช่นกัน
สำหรับโหมด remote การสร้างใหม่มีความสำคัญเป็นพิเศษ:
  • การสร้างใหม่จะลบพื้นที่ทำงานระยะไกลที่เป็นแหล่งข้อมูลหลักสำหรับ scope นั้น
  • การใช้งานครั้งถัดไปจะเติมข้อมูลพื้นที่ทำงานระยะไกลใหม่จากพื้นที่ทำงานภายในเครื่อง
สำหรับโหมด mirror การสร้างใหม่ส่วนใหญ่จะรีเซ็ตสภาพแวดล้อมการรันงานระยะไกล เพราะพื้นที่ทำงานภายในเครื่องยังคงเป็นแหล่งข้อมูลหลักอยู่แล้ว

การเข้าถึงพื้นที่ทำงาน

agents.defaults.sandbox.workspaceAccess ควบคุมว่า sandbox มองเห็นอะไรได้บ้าง:
เครื่องมือเห็นพื้นที่ทำงาน sandbox ภายใต้ ~/.openclaw/sandboxes
เมื่อใช้ OpenShell backend:
  • โหมด mirror ยังคงใช้พื้นที่ทำงานภายในเครื่องเป็นแหล่งข้อมูลหลักระหว่างเทิร์น exec
  • โหมด remote ใช้พื้นที่ทำงาน OpenShell ระยะไกลเป็นแหล่งข้อมูลหลักหลังการเติมข้อมูลเริ่มต้น
  • workspaceAccess: "ro" และ "none" ยังคงจำกัดพฤติกรรมการเขียนในแบบเดียวกัน
สื่อขาเข้าจะถูกคัดลอกเข้าไปในพื้นที่ทำงาน sandbox ที่ใช้งานอยู่ (media/inbound/*)
หมายเหตุเกี่ยวกับ Skills: เครื่องมือ read อิงรากของ sandbox เมื่อใช้ workspaceAccess: "none" OpenClaw จะ mirror skills ที่เข้าเงื่อนไขเข้าไปในพื้นที่ทำงาน sandbox (.../skills) เพื่อให้อ่านได้ เมื่อใช้ "rw" skills ในพื้นที่ทำงานจะอ่านได้จาก /workspace/skills

bind mount แบบกำหนดเอง

agents.defaults.sandbox.docker.binds เมานต์ไดเรกทอรีโฮสต์เพิ่มเติมเข้าไปใน container รูปแบบ: host:container:mode (เช่น "/home/user/source:/source:rw") bind ระดับ global และต่อ agent จะถูก ผสาน กัน (ไม่ใช่แทนที่กัน) ภายใต้ scope: "shared" bind ต่อ agent จะถูกละเว้น agents.defaults.sandbox.browser.binds เมานต์ไดเรกทอรีโฮสต์เพิ่มเติมเข้าไปใน container sandbox browser เท่านั้น
  • เมื่อตั้งค่าไว้ (รวมถึง []) ค่านี้จะแทนที่ agents.defaults.sandbox.docker.binds สำหรับ browser container
  • เมื่อละไว้ browser container จะ fallback ไปใช้ agents.defaults.sandbox.docker.binds (เข้ากันได้ย้อนหลัง)
ตัวอย่าง (ซอร์สแบบอ่านอย่างเดียว + ไดเรกทอรีข้อมูลเพิ่มเติม):
{
  agents: {
    defaults: {
      sandbox: {
        docker: {
          binds: ["/home/user/source:/source:ro", "/var/data/myapp:/data:ro"],
        },
      },
    },
    list: [
      {
        id: "build",
        sandbox: {
          docker: {
            binds: ["/mnt/cache:/cache:rw"],
          },
        },
      },
    ],
  },
}
ความปลอดภัยของ bind
  • bind ข้ามระบบไฟล์ของ sandbox: ทำให้ path ของโฮสต์ถูกเปิดเผยด้วยโหมดที่คุณตั้งไว้ (:ro หรือ :rw)
  • OpenClaw บล็อกแหล่ง bind ที่อันตราย (ตัวอย่างเช่น docker.sock, /etc, /proc, /sys, /dev และ parent mount ที่จะเปิดเผยสิ่งเหล่านี้)
  • OpenClaw ยังบล็อกรากของข้อมูลประจำตัวใน home directory ที่พบบ่อย เช่น ~/.aws, ~/.cargo, ~/.config, ~/.docker, ~/.gnupg, ~/.netrc, ~/.npm และ ~/.ssh
  • การตรวจสอบ bind ไม่ใช่แค่การจับคู่สตริง OpenClaw จะ normalize path ต้นทาง แล้ว resolve อีกครั้งผ่าน ancestor ที่มีอยู่ลึกที่สุด ก่อนตรวจสอบ path ที่ถูกบล็อกและรากที่อนุญาตซ้ำ
  • นั่นหมายความว่าการหลบหนีผ่าน parent ที่เป็น symlink ยังคงถูกปิดกั้น แม้ leaf สุดท้ายจะยังไม่มีอยู่ก็ตาม ตัวอย่าง: /workspace/run-link/new-file ยังคง resolve เป็น /var/run/... หาก run-link ชี้ไปที่นั่น
  • รากต้นทางที่อนุญาตจะถูก canonicalize ด้วยวิธีเดียวกัน ดังนั้น path ที่ดูเหมือนอยู่ใน allowlist ก่อนการ resolve symlink ก็ยังถูกปฏิเสธเป็น outside allowed roots
  • mount ที่ละเอียดอ่อน (secrets, SSH keys, service credentials) ควรเป็น :ro เว้นแต่จำเป็นจริงๆ
  • ใช้ร่วมกับ workspaceAccess: "ro" หากคุณต้องการเพียงสิทธิ์อ่านพื้นที่ทำงาน; โหมด bind ยังคงเป็นอิสระต่อกัน
  • ดู Sandbox vs Tool Policy vs Elevated สำหรับวิธีที่ bind โต้ตอบกับ tool policy และ elevated exec

Images และการตั้งค่า

Docker image เริ่มต้น: openclaw-sandbox:bookworm-slim
Source checkout เทียบกับ npm installสคริปต์ตัวช่วย scripts/sandbox-setup.sh, scripts/sandbox-common-setup.sh และ scripts/sandbox-browser-setup.sh มีให้ใช้เฉพาะเมื่อรันจาก source checkout เท่านั้น สคริปต์เหล่านี้ไม่ได้รวมอยู่ใน npm packageหากคุณติดตั้ง OpenClaw ผ่าน npm install -g openclaw ให้ใช้คำสั่ง docker build แบบ inline ที่แสดงด้านล่างแทน
1

Build the default image

จาก source checkout:
scripts/sandbox-setup.sh
จากการติดตั้งผ่าน npm (ไม่ต้องมี source checkout):
docker build -t openclaw-sandbox:bookworm-slim - <<'DOCKERFILE'
FROM debian:bookworm-slim
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y --no-install-recommends \
  bash ca-certificates curl git jq python3 ripgrep \
  && rm -rf /var/lib/apt/lists/*
RUN useradd --create-home --shell /bin/bash sandbox
USER sandbox
WORKDIR /home/sandbox
CMD ["sleep", "infinity"]
DOCKERFILE
image เริ่มต้น ไม่มี Node หาก skill ต้องใช้ Node (หรือ runtime อื่น) ให้ bake image แบบกำหนดเองหรือติดตั้งผ่าน sandbox.docker.setupCommand (ต้องมี network egress + root ที่เขียนได้ + ผู้ใช้ root)OpenClaw จะไม่แทนที่ด้วย debian:bookworm-slim ธรรมดาอย่างเงียบๆ เมื่อไม่มี openclaw-sandbox:bookworm-slim การรัน sandbox ที่เล็งไปยัง image เริ่มต้นจะล้มเหลวทันทีพร้อมคำแนะนำการ build จนกว่าคุณจะ build image นั้น เพราะ image ที่บันเดิลมาพก python3 สำหรับตัวช่วยเขียน/แก้ไขใน sandbox
2

Optional: build the common image

สำหรับ sandbox image ที่ใช้งานได้ครบขึ้นพร้อมเครื่องมือทั่วไป (ตัวอย่างเช่น curl, jq, nodejs, python3, git):จาก source checkout:
scripts/sandbox-common-setup.sh
จากการติดตั้งผ่าน npm ให้ build image เริ่มต้นก่อน (ดูด้านบน) จากนั้น build common image ต่อบน image นั้นโดยใช้ scripts/docker/sandbox/Dockerfile.common จาก repositoryจากนั้นตั้งค่า agents.defaults.sandbox.docker.image เป็น openclaw-sandbox-common:bookworm-slim
3

Optional: build the sandbox browser image

จาก source checkout:
scripts/sandbox-browser-setup.sh
จากการติดตั้งผ่าน npm ให้ build โดยใช้ scripts/docker/sandbox/Dockerfile.browser จาก repository
โดยค่าเริ่มต้น Docker sandbox container จะรันโดย ไม่มี network แทนที่ได้ด้วย agents.defaults.sandbox.docker.network
bundled sandbox browser image ยังใช้ค่าเริ่มต้นการเริ่มทำงานของ Chromium แบบระมัดระวังสำหรับ workload ใน container ด้วย ค่าเริ่มต้นของ container ปัจจุบันประกอบด้วย:
  • --remote-debugging-address=127.0.0.1
  • --remote-debugging-port=<derived from OPENCLAW_BROWSER_CDP_PORT>
  • --user-data-dir=${HOME}/.chrome
  • --no-first-run
  • --no-default-browser-check
  • --disable-3d-apis
  • --disable-gpu
  • --disable-dev-shm-usage
  • --disable-background-networking
  • --disable-extensions
  • --disable-features=TranslateUI
  • --disable-breakpad
  • --disable-crash-reporter
  • --disable-software-rasterizer
  • --no-zygote
  • --metrics-recording-only
  • --renderer-process-limit=2
  • --no-sandbox เมื่อเปิดใช้งาน noSandbox
  • flag เสริมความปลอดภัยกราฟิกสามรายการ (--disable-3d-apis, --disable-software-rasterizer, --disable-gpu) เป็นแบบเลือกใช้ได้ และมีประโยชน์เมื่อ container ไม่มีการรองรับ GPU ตั้งค่า OPENCLAW_BROWSER_DISABLE_GRAPHICS_FLAGS=0 หาก workload ของคุณต้องใช้ WebGL หรือฟีเจอร์ 3D/browser อื่น
  • --disable-extensions เปิดใช้งานโดยค่าเริ่มต้น และปิดใช้งานได้ด้วย OPENCLAW_BROWSER_DISABLE_EXTENSIONS=0 สำหรับ flow ที่พึ่งพา extension
  • --renderer-process-limit=2 ถูกควบคุมโดย OPENCLAW_BROWSER_RENDERER_PROCESS_LIMIT=<N> โดย 0 จะคงค่าเริ่มต้นของ Chromium
หากคุณต้องการ runtime profile ที่ต่างออกไป ให้ใช้ browser image แบบกำหนดเองและระบุ entrypoint ของคุณเอง สำหรับ Chromium profile แบบ local (ไม่ใช่ container) ให้ใช้ browser.extraArgs เพื่อเพิ่ม startup flag เพิ่มเติม
  • network: "host" ถูกบล็อก
  • network: "container:<id>" ถูกบล็อกโดยค่าเริ่มต้น (ความเสี่ยงจากการข้ามผ่านด้วย namespace join)
  • override สำหรับกรณีฉุกเฉิน: agents.defaults.sandbox.docker.dangerouslyAllowContainerNamespaceJoin: true
การติดตั้ง Docker และ Gateway แบบ container อยู่ที่นี่: Docker สำหรับการ deploy Docker gateway, scripts/docker/setup.sh สามารถ bootstrap config ของ sandbox ได้ ตั้งค่า OPENCLAW_SANDBOX=1 (หรือ true/yes/on) เพื่อเปิดใช้งาน path นั้น คุณสามารถแทนที่ตำแหน่ง socket ได้ด้วย OPENCLAW_DOCKER_SOCKET การตั้งค่าเต็มรูปแบบและเอกสารอ้างอิง env: Docker

setupCommand (การตั้งค่า container แบบครั้งเดียว)

setupCommand รัน ครั้งเดียว หลังจากสร้าง sandbox container แล้ว (ไม่ใช่ทุกครั้งที่รัน) โดยจะ execute ภายใน container ผ่าน sh -lc Path:
  • Global: agents.defaults.sandbox.docker.setupCommand
  • ต่อ agent: agents.list[].sandbox.docker.setupCommand
  • ค่าเริ่มต้นของ docker.network คือ "none" (ไม่มี egress) ดังนั้นการติดตั้งแพ็กเกจจะล้มเหลว
  • docker.network: "container:<id>" ต้องใช้ dangerouslyAllowContainerNamespaceJoin: true และใช้เฉพาะกรณีฉุกเฉินเท่านั้น
  • readOnlyRoot: true ป้องกันการเขียน ให้ตั้งค่า readOnlyRoot: false หรือสร้างอิมเมจแบบกำหนดเองไว้ล่วงหน้า
  • user ต้องเป็น root สำหรับการติดตั้งแพ็กเกจ (ละ user ไว้ หรือตั้งค่า user: "0:0")
  • การ exec ใน sandbox ไม่ สืบทอด process.env ของโฮสต์ ใช้ agents.defaults.sandbox.docker.env (หรืออิมเมจแบบกำหนดเอง) สำหรับคีย์ API ของ Skills

นโยบายเครื่องมือและทางออกฉุกเฉิน

นโยบายอนุญาต/ปฏิเสธเครื่องมือยังคงมีผลก่อนกฎ sandbox หากเครื่องมือถูกปฏิเสธแบบทั่วระบบหรือต่อ agent การ sandbox จะไม่นำเครื่องมือนั้นกลับมา tools.elevated เป็นทางออกฉุกเฉินแบบชัดเจนที่รัน exec นอก sandbox (gateway เป็นค่าเริ่มต้น หรือ node เมื่อเป้าหมาย exec คือ node) คำสั่ง /exec มีผลเฉพาะกับผู้ส่งที่ได้รับอนุญาตและคงอยู่ต่อเซสชัน หากต้องการปิดใช้งาน exec อย่างเด็ดขาด ให้ใช้นโยบายเครื่องมือแบบ deny (ดู Sandbox เทียบกับนโยบายเครื่องมือเทียบกับ Elevated) การดีบัก: ล็อกให้แน่นหนาไว้

การ override สำหรับหลาย agent

แต่ละ agent สามารถ override sandbox + tools ได้: agents.list[].sandbox และ agents.list[].tools (รวมถึง agents.list[].tools.sandbox.tools สำหรับนโยบายเครื่องมือของ sandbox) ดู Sandbox และเครื่องมือสำหรับหลาย Agent สำหรับลำดับความสำคัญ

ตัวอย่างเปิดใช้งานขั้นต่ำ

{
  agents: {
    defaults: {
      sandbox: {
        mode: "non-main",
        scope: "session",
        workspaceAccess: "none",
      },
    },
  },
}

ที่เกี่ยวข้อง