OpenClaw สามารถเรียกใช้ เครื่องมือภายในแบ็กเอนด์ sandbox เพื่อลดขอบเขตผลกระทบได้ สิ่งนี้เป็น ตัวเลือก และควบคุมด้วยการกำหนดค่า (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.
agents.defaults.sandbox หรือ agents.list[].sandbox) หากปิด sandboxing เครื่องมือจะทำงานบนโฮสต์ Gateway จะยังอยู่บนโฮสต์ ส่วนการเรียกใช้เครื่องมือจะทำงานใน sandbox ที่แยกออกมาเมื่อเปิดใช้งาน
นี่ไม่ใช่ขอบเขตความปลอดภัยที่สมบูรณ์แบบ แต่ช่วยจำกัดการเข้าถึงระบบไฟล์และโพรเซสได้อย่างมีนัยสำคัญเมื่อโมเดลทำสิ่งที่ไม่สมเหตุสมผล
สิ่งที่จะถูก sandbox
- การเรียกใช้เครื่องมือ (
exec,read,write,edit,apply_patch,processฯลฯ) - เบราว์เซอร์ใน sandbox ที่เป็นตัวเลือก (
agents.defaults.sandbox.browser)
รายละเอียดเบราว์เซอร์ใน sandbox
รายละเอียดเบราว์เซอร์ใน sandbox
- โดยค่าเริ่มต้น เบราว์เซอร์ใน 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
- โพรเซส Gateway เอง
- เครื่องมือใดก็ตามที่อนุญาตอย่างชัดเจนให้ทำงานนอก sandbox (เช่น
tools.elevated)- Elevated exec จะข้าม sandboxing และใช้เส้นทาง escape ที่กำหนดค่าไว้ (
gatewayโดยค่าเริ่มต้น หรือnodeเมื่อเป้าหมาย exec คือnode) - หากปิด sandboxing อยู่
tools.elevatedจะไม่เปลี่ยนแปลงการเรียกใช้ (อยู่บนโฮสต์อยู่แล้ว) ดู โหมด Elevated
- Elevated exec จะข้าม sandboxing และใช้เส้นทาง escape ที่กำหนดค่าไว้ (
โหมด
agents.defaults.sandbox.mode ควบคุมว่าจะใช้ sandboxing เมื่อใด:
- off
- non-main
- all
ไม่มี 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
agents.defaults.sandbox.ssh การกำหนดค่าเฉพาะ OpenShell อยู่ใต้ plugins.entries.openshell.config
การเลือกแบ็กเอนด์
| Docker | SSH | OpenShell | |
|---|---|---|---|
| ตำแหน่งที่ทำงาน | คอนเทนเนอร์ภายในเครื่อง | โฮสต์ใดก็ได้ที่เข้าถึงได้ผ่าน SSH | sandbox ที่จัดการโดย OpenShell |
| การตั้งค่า | scripts/sandbox-setup.sh | คีย์ SSH + โฮสต์เป้าหมาย | เปิดใช้งาน Plugin OpenShell |
| โมเดล workspace | Bind-mount หรือ copy | Remote-canonical (seed ครั้งเดียว) | mirror หรือ remote |
| การควบคุมเครือข่าย | docker.network (ค่าเริ่มต้น: none) | ขึ้นอยู่กับโฮสต์ระยะไกล | ขึ้นอยู่กับ OpenShell |
| เบราว์เซอร์ sandbox | รองรับ | ไม่รองรับ | ยังไม่รองรับ |
| Bind mounts | docker.binds | N/A | N/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
แบ็กเอนด์ SSH
ใช้backend: "ssh" เมื่อคุณต้องการให้ OpenClaw sandbox exec, เครื่องมือไฟล์ และการอ่านสื่อบนเครื่องใดก็ได้ที่เข้าถึงได้ผ่าน SSH
วิธีการทำงาน
วิธีการทำงาน
- OpenClaw สร้าง root ระยะไกลต่อขอบเขตภายใต้
sandbox.ssh.workspaceRoot - เมื่อใช้ครั้งแรกหลังจากสร้างหรือสร้างใหม่ OpenClaw จะ seed workspace ระยะไกลนั้นจาก workspace ภายในเครื่องหนึ่งครั้ง
- หลังจากนั้น
exec,read,write,edit,apply_patch, การอ่านสื่อของ prompt และการ staging สื่อขาเข้า จะทำงานกับ workspace ระยะไกลโดยตรงผ่าน SSH - OpenClaw ไม่ซิงก์การเปลี่ยนแปลงระยะไกลกลับไปยัง workspace ภายในเครื่องโดยอัตโนมัติ
วัสดุสำหรับการยืนยันตัวตน
วัสดุสำหรับการยืนยันตัวตน
identityFile,certificateFile,knownHostsFile: ใช้ไฟล์ภายในเครื่องที่มีอยู่และส่งผ่านการกำหนดค่า OpenSSHidentityData,certificateData,knownHostsData: ใช้สตริงแบบ inline หรือ SecretRefs OpenClaw จะแก้ค่าเหล่านี้ผ่าน snapshot runtime ของ secrets ตามปกติ เขียนลงไฟล์ temp ด้วย0600และลบเมื่อเซสชัน SSH จบลง- หากตั้งค่าทั้ง
*Fileและ*Dataสำหรับรายการเดียวกัน*Dataจะชนะสำหรับเซสชัน SSH นั้น
ผลลัพธ์ของ remote-canonical
ผลลัพธ์ของ remote-canonical
นี่คือโมเดล 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 ที่เป็นตัวเลือก
mirror(ค่าเริ่มต้น): workspace ภายในเครื่องยังคงเป็น canonical OpenClaw จะซิงก์ไฟล์ภายในเครื่องเข้า OpenShell ก่อน exec และซิงก์ workspace ระยะไกลกลับหลัง execremote: workspace ของ OpenShell เป็น canonical หลังจากสร้าง sandbox แล้ว OpenClaw จะ seed workspace ระยะไกลหนึ่งครั้งจาก workspace ภายในเครื่อง จากนั้นเครื่องมือไฟล์และ exec จะทำงานกับ sandbox ระยะไกลโดยตรงโดยไม่ซิงก์การเปลี่ยนแปลงกลับ
รายละเอียด transport ระยะไกล
รายละเอียด transport ระยะไกล
- OpenClaw ขอการกำหนดค่า SSH เฉพาะ sandbox จาก OpenShell ผ่าน
openshell sandbox ssh-config <name> - Core เขียนการกำหนดค่า SSH นั้นลงไฟล์ temp เปิดเซสชัน SSH และใช้ bridge ระบบไฟล์ระยะไกลเดียวกันกับที่ใช้โดย
backend: "ssh" - ในโหมด
mirrorมีเพียง lifecycle เท่านั้นที่ต่างออกไป: ซิงก์จากภายในเครื่องไปยังระยะไกลก่อน exec แล้วซิงก์กลับหลัง exec
ข้อจำกัดปัจจุบันของ OpenShell
ข้อจำกัดปัจจุบันของ OpenShell
- ยังไม่รองรับเบราว์เซอร์ sandbox
sandbox.docker.bindsไม่รองรับบนแบ็กเอนด์ OpenShell- knob runtime เฉพาะ Docker ภายใต้
sandbox.docker.*ยังคงมีผลเฉพาะกับแบ็กเอนด์ Docker เท่านั้น
โหมด workspace
OpenShell มีโมเดล workspace สองแบบ นี่คือส่วนที่สำคัญที่สุดในทางปฏิบัติ- mirror (local canonical)
- remote (OpenShell canonical)
ใช้
plugins.entries.openshell.config.mode: "mirror" เมื่อคุณต้องการให้ workspace ภายในเครื่องยังคงเป็น canonicalพฤติกรรม:- ก่อน
execOpenClaw จะซิงก์พื้นที่ทำงานภายในเครื่องเข้าไปใน OpenShell sandbox - หลัง
execOpenClaw จะซิงก์พื้นที่ทำงานระยะไกลกลับมายังพื้นที่ทำงานภายในเครื่อง - เครื่องมือไฟล์ยังคงทำงานผ่าน sandbox bridge แต่พื้นที่ทำงานภายในเครื่องยังเป็นแหล่งข้อมูลหลักระหว่างเทิร์น
- คุณแก้ไขไฟล์ภายในเครื่องนอก OpenClaw และต้องการให้การเปลี่ยนแปลงเหล่านั้นปรากฏใน sandbox โดยอัตโนมัติ
- คุณต้องการให้ OpenShell sandbox ทำงานคล้ายกับ Docker backend มากที่สุดเท่าที่เป็นไปได้
- คุณต้องการให้พื้นที่ทำงานของโฮสต์สะท้อนการเขียนใน sandbox หลังแต่ละเทิร์น exec
mirror หากคุณมอง sandbox เป็นสภาพแวดล้อมสำหรับการรันงานชั่วคราว เลือก remote หากคุณมอง sandbox เป็นพื้นที่ทำงานจริง
วงจรชีวิต OpenShell
OpenShell sandbox ยังคงถูกจัดการผ่านวงจรชีวิต sandbox ตามปกติ:openclaw sandbox listแสดง OpenShell runtime รวมถึง Docker runtimeopenclaw sandbox recreateลบ runtime ปัจจุบันและให้ OpenClaw สร้างใหม่เมื่อใช้งานครั้งถัดไป- ตรรกะ prune ก็รับรู้ backend เช่นกัน
remote การสร้างใหม่มีความสำคัญเป็นพิเศษ:
- การสร้างใหม่จะลบพื้นที่ทำงานระยะไกลที่เป็นแหล่งข้อมูลหลักสำหรับ scope นั้น
- การใช้งานครั้งถัดไปจะเติมข้อมูลพื้นที่ทำงานระยะไกลใหม่จากพื้นที่ทำงานภายในเครื่อง
mirror การสร้างใหม่ส่วนใหญ่จะรีเซ็ตสภาพแวดล้อมการรันงานระยะไกล เพราะพื้นที่ทำงานภายในเครื่องยังคงเป็นแหล่งข้อมูลหลักอยู่แล้ว
การเข้าถึงพื้นที่ทำงาน
agents.defaults.sandbox.workspaceAccess ควบคุมว่า sandbox มองเห็นอะไรได้บ้าง:
- none (default)
- ro
- rw
เครื่องมือเห็นพื้นที่ทำงาน sandbox ภายใต้
~/.openclaw/sandboxes- โหมด
mirrorยังคงใช้พื้นที่ทำงานภายในเครื่องเป็นแหล่งข้อมูลหลักระหว่างเทิร์น exec - โหมด
remoteใช้พื้นที่ทำงาน OpenShell ระยะไกลเป็นแหล่งข้อมูลหลักหลังการเติมข้อมูลเริ่มต้น workspaceAccess: "ro"และ"none"ยังคงจำกัดพฤติกรรมการเขียนในแบบเดียวกัน
media/inbound/*)
หมายเหตุเกี่ยวกับ Skills: เครื่องมือ
read อิงรากของ sandbox เมื่อใช้ workspaceAccess: "none" OpenClaw จะ mirror skills ที่เข้าเงื่อนไขเข้าไปในพื้นที่ทำงาน sandbox (.../skills) เพื่อให้อ่านได้ เมื่อใช้ "rw" skills ในพื้นที่ทำงานจะอ่านได้จาก /workspace/skillsbind 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(เข้ากันได้ย้อนหลัง)
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 ที่แสดงด้านล่างแทนBuild the default image
จาก source checkout:จากการติดตั้งผ่าน npm (ไม่ต้องมี source checkout):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 สำหรับตัวช่วยเขียน/แก้ไขใน sandboxOptional: build the common image
สำหรับ sandbox image ที่ใช้งานได้ครบขึ้นพร้อมเครื่องมือทั่วไป (ตัวอย่างเช่น จากการติดตั้งผ่าน npm ให้ build image เริ่มต้นก่อน (ดูด้านบน) จากนั้น build common image ต่อบน image นั้นโดยใช้
curl, jq, nodejs, python3, git):จาก source checkout:scripts/docker/sandbox/Dockerfile.common จาก repositoryจากนั้นตั้งค่า agents.defaults.sandbox.docker.image เป็น openclaw-sandbox-common:bookworm-slimOptional: build the sandbox browser image
จาก source checkout:จากการติดตั้งผ่าน npm ให้ build โดยใช้
scripts/docker/sandbox/Dockerfile.browser จาก repositoryagents.defaults.sandbox.docker.network
Sandbox browser Chromium defaults
Sandbox browser Chromium defaults
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
browser.extraArgs เพื่อเพิ่ม startup flag เพิ่มเติมNetwork security defaults
Network security defaults
network: "host"ถูกบล็อกnetwork: "container:<id>"ถูกบล็อกโดยค่าเริ่มต้น (ความเสี่ยงจากการข้ามผ่านด้วย namespace join)- override สำหรับกรณีฉุกเฉิน:
agents.defaults.sandbox.docker.dangerouslyAllowContainerNamespaceJoin: true
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)
การดีบัก:
- ใช้
openclaw sandbox explainเพื่อตรวจสอบโหมด sandbox ที่มีผลจริง นโยบายเครื่องมือ และคีย์ config สำหรับแก้ไข - ดู Sandbox เทียบกับนโยบายเครื่องมือเทียบกับ Elevated สำหรับกรอบคิด “ทำไมสิ่งนี้จึงถูกบล็อก?”
การ override สำหรับหลาย agent
แต่ละ agent สามารถ override sandbox + tools ได้:agents.list[].sandbox และ agents.list[].tools (รวมถึง agents.list[].tools.sandbox.tools สำหรับนโยบายเครื่องมือของ sandbox) ดู Sandbox และเครื่องมือสำหรับหลาย Agent สำหรับลำดับความสำคัญ
ตัวอย่างเปิดใช้งานขั้นต่ำ
ที่เกี่ยวข้อง
- Sandbox และเครื่องมือสำหรับหลาย Agent — การ override ราย agent และลำดับความสำคัญ
- OpenShell — การตั้งค่า backend sandbox ที่มีการจัดการ โหมด workspace และเอกสารอ้างอิง config
- การกำหนดค่า Sandbox
- Sandbox เทียบกับนโยบายเครื่องมือเทียบกับ Elevated — การดีบัก “ทำไมสิ่งนี้จึงถูกบล็อก?”
- ความปลอดภัย