การอนุมัติการเรียกใช้คำสั่ง

การอนุมัติ exec คือ แนวป้องกันของแอปคู่หู / โฮสต์ node สำหรับให้ เอเจนต์ใน sandbox รันคำสั่งบนโฮสต์จริง (gateway หรือ node) เป็น กลไกนิรภัย: อนุญาตคำสั่งได้ต่อเมื่อนโยบาย + allowlist + การอนุมัติจากผู้ใช้ (ไม่บังคับ) เห็นตรงกันทั้งหมด การอนุมัติ exec ซ้อนอยู่ เหนือ นโยบายเครื่องมือและเกตการยกระดับ (ยกเว้นเมื่อตั้ง elevated เป็น full ซึ่ง จะข้ามการอนุมัติ)

สำหรับภาพรวมแบบเน้นโหมดของ deny, allowlist, ask, auto, full, การแมป Codex Guardian และสิทธิ์ harness ของ ACPX โปรดดู โหมดสิทธิ์

การตรวจสอบนโยบายที่มีผล

เมื่อ scope ภายในขอ host=node คำสั่ง exec-policy show จะรายงานว่า scope นั้นถูกจัดการโดย node ขณะรัน แทนที่จะแสร้งว่าไฟล์การอนุมัติภายใน คือแหล่งความจริง

หาก UI ของแอปคู่หู ไม่พร้อมใช้งาน คำขอใดก็ตามที่ปกติจะ แสดง prompt จะถูกตัดสินด้วย ask fallback (ค่าเริ่มต้น: deny)

ใช้กับที่ใด

การอนุมัติ exec ถูกบังคับใช้ภายในเครื่องบนโฮสต์ที่ทำการรัน:

• โฮสต์ Gateway → โปรเซส openclaw บนเครื่อง gateway
• โฮสต์ Node → ตัวรัน node (แอปคู่หู macOS หรือโฮสต์ node แบบ headless)

โมเดลความเชื่อถือ

• ผู้เรียกที่ผ่านการยืนยันตัวตนกับ Gateway ถือเป็นผู้ปฏิบัติการที่เชื่อถือได้สำหรับ Gateway นั้น
• node ที่จับคู่แล้วจะขยายความสามารถของผู้ปฏิบัติการที่เชื่อถือได้นั้นไปยังโฮสต์ node
• การอนุมัติ exec ลดความเสี่ยงจากการรันโดยไม่ตั้งใจ แต่ ไม่ใช่ ขอบเขตการยืนยันตัวตนรายผู้ใช้หรือนโยบายระบบไฟล์แบบอ่านอย่างเดียว
• เมื่ออนุมัติแล้ว คำสั่งสามารถเปลี่ยนแปลงไฟล์ได้ตามสิทธิ์ระบบไฟล์ของโฮสต์หรือ sandbox ที่เลือก
• การรันบนโฮสต์ node ที่อนุมัติแล้วจะผูกบริบทการรันมาตรฐาน: cwd มาตรฐาน, argv ที่แน่นอน, การผูก env เมื่อมี และพาธ executable ที่ปักหมุดไว้เมื่อใช้ได้
• สำหรับสคริปต์ shell และการเรียกไฟล์ interpreter/runtime โดยตรง OpenClaw ยังพยายามผูก operand ไฟล์ภายในเครื่องที่เป็นรูปธรรมหนึ่งไฟล์ หากไฟล์ที่ผูกไว้นั้นเปลี่ยนหลังการอนุมัติแต่ก่อนรัน การรันจะถูกปฏิเสธแทนการรันเนื้อหาที่เปลี่ยนไป
• การผูกไฟล์เป็นแบบ best-effort โดยตั้งใจ ไม่ใช่ โมเดลเชิงความหมายที่ครบถ้วนของทุกพาธ loader ของ interpreter/runtime หากโหมดอนุมัติไม่สามารถระบุไฟล์ภายในเครื่องที่เป็นรูปธรรมได้แน่นอนหนึ่งไฟล์เพื่อผูกไว้ ก็จะปฏิเสธการสร้างการรันที่อิงการอนุมัติ แทนที่จะแสร้งว่าครอบคลุมทั้งหมด

การแยกใน macOS

• บริการโฮสต์ node ส่งต่อ system.run ไปยัง แอป macOS ผ่าน IPC ภายใน
• แอป macOS บังคับใช้การอนุมัติและรันคำสั่งในบริบท UI

การตั้งค่าและที่จัดเก็บ

การอนุมัติอยู่ในไฟล์ JSON ภายในเครื่องบนโฮสต์ที่ทำการรัน เมื่อ ตั้งค่า OPENCLAW_STATE_DIR ไฟล์จะอยู่ตามไดเรกทอรีสถานะนั้น มิฉะนั้นจะใช้ไดเรกทอรีสถานะเริ่มต้นของ OpenClaw:

$OPENCLAW_STATE_DIR/exec-approvals.json# otherwise~/.openclaw/exec-approvals.json

socket การอนุมัติเริ่มต้นใช้ root เดียวกัน: $OPENCLAW_STATE_DIR/exec-approvals.sock หรือ ~/.openclaw/exec-approvals.sock เมื่อไม่ได้ตั้งค่าตัวแปร

ตัวอย่าง schema:

{  "version": 1,  "socket": {    "path": "~/.openclaw/exec-approvals.sock",    "token": "base64url-token"  },  "defaults": {    "security": "deny",    "ask": "on-miss",    "askFallback": "deny",    "autoAllowSkills": false  },  "agents": {    "main": {      "security": "allowlist",      "ask": "on-miss",      "askFallback": "deny",      "autoAllowSkills": true,      "allowlist": [        {          "id": "B0C8C0B3-2C2D-4F8A-9A3C-5A4B3C2D1E0F",          "pattern": "~/Projects/**/bin/rg",          "source": "allow-always",          "commandText": "rg -n TODO",          "lastUsedAt": 1737150000000,          "lastUsedCommand": "rg -n TODO",          "lastResolvedPath": "/Users/user/Projects/.../bin/rg"        }      ]    }  }}

ปุ่มปรับนโยบาย

tools.exec.mode

tools.exec.mode คือพื้นผิวนโยบายที่ทำให้เป็นมาตรฐานแล้วที่แนะนำสำหรับ host exec ค่าคือ:

• deny - บล็อก host exec
• allowlist - รันเฉพาะคำสั่งใน allowlist โดยไม่ถาม
• ask - ใช้นโยบาย allowlist และถามเมื่อไม่ตรงกัน
• auto - ใช้นโยบาย allowlist, รันรายการที่ตรงกันแบบกำหนดได้โดยตรง และส่งรายการที่พลาดการอนุมัติผ่านตัวรีวิวอัตโนมัติเนทีฟของ OpenClaw ก่อน fallback ไปยังเส้นทางอนุมัติจากมนุษย์
• full - รัน host exec โดยไม่มี prompt การอนุมัติ

tools.exec.security / tools.exec.ask แบบเก่ายังคงรองรับและยังมีผลเหนือกว่า เมื่อตั้งไว้ใน scope เซสชันหรือเอเจนต์ที่แคบกว่า

exec.security

exec.ask

askFallback

tools.exec.strictInlineEval

ตัวอย่างที่โหมด strict ตรวจจับ:

• python -c
• node -e, node --eval, node -p
• ruby -e
• perl -e, perl -E
• php -r
• lua -e
• osascript -e

ในโหมด strict คำสั่งเหล่านี้ยังต้องมีการอนุมัติชัดเจน และ allow-always จะไม่คงรายการ allowlist ใหม่ให้คำสั่งเหล่านี้ โดยอัตโนมัติ

tools.exec.commandHighlighting

การตั้งค่านี้ ไม่ เปลี่ยน security, ask, การจับคู่ allowlist, พฤติกรรม strict inline-eval, การส่งต่อการอนุมัติ หรือการรันคำสั่ง สามารถตั้งค่าแบบทั่วทั้งระบบภายใต้ tools.exec.commandHighlighting หรือราย เอเจนต์ภายใต้ agents.list[].tools.exec.commandHighlighting

โหมด YOLO (ไม่มีการอนุมัติ)

หากคุณต้องการให้ host exec รันโดยไม่มี prompt การอนุมัติ คุณต้องเปิด ชั้นนโยบาย ทั้งสอง ชั้น - นโยบาย exec ที่ขอใน config ของ OpenClaw (tools.exec.*) และ นโยบายการอนุมัติแบบ host-local ใน ไฟล์การอนุมัติของโฮสต์ที่ทำการรัน

OpenClaw ตั้งค่าเริ่มต้นของ askFallback ที่ละเว้นไว้เป็น deny ตั้งค่า askFallback ของโฮสต์เป็น full อย่างชัดเจนเมื่อ prompt การอนุมัติที่ไม่มี UI ควร fallback เป็นอนุญาต

ผู้ให้บริการที่รองรับด้วย CLI ซึ่งเปิดเผยโหมดสิทธิ์ noninteractive ของตนเอง สามารถทำตามนโยบายนี้ได้ Claude CLI จะเพิ่ม --permission-mode bypassPermissions เมื่อนโยบาย exec ที่มีผลของ OpenClaw เป็น YOLO สำหรับเซสชัน Claude live ที่ OpenClaw จัดการ นโยบาย exec ที่มีผลของ OpenClaw เป็นตัวกำหนดเหนือกว่าโหมดสิทธิ์เนทีฟของ Claude: YOLO จะทำให้การเปิด live เป็น --permission-mode bypassPermissions และ นโยบาย exec ที่มีผลแบบจำกัดจะทำให้การเปิด live เป็น --permission-mode default แม้ raw Claude backend args จะระบุโหมดอื่นก็ตาม

หากต้องการการตั้งค่าที่ระมัดระวังกว่า ให้ปรับนโยบาย exec ของ OpenClaw กลับเป็น allowlist / on-miss หรือ deny

การตั้งค่า gateway-host แบบถาวรที่ "ไม่ต้องถาม"

openclaw config set tools.exec.host gatewayopenclaw config set tools.exec.security fullopenclaw config set tools.exec.ask offopenclaw gateway restart

openclaw approvals set --stdin <<'EOF'{  version: 1,  defaults: {    security: "full",    ask: "off",    askFallback: "full"  }}EOF

ทางลัดภายในเครื่อง

openclaw exec-policy preset yolo

ทางลัดภายในเครื่องนั้นอัปเดตทั้งสองอย่าง:

• tools.exec.host/security/ask ภายในเครื่อง
• ค่าเริ่มต้นของไฟล์การอนุมัติภายในเครื่อง รวมถึง askFallback: "full"

ตั้งใจให้เป็นแบบภายในเครื่องเท่านั้น หากต้องการเปลี่ยนการอนุมัติ gateway-host หรือ node-host จากระยะไกล ให้ใช้ openclaw approvals set --gateway หรือ openclaw approvals set --node <id|name|ip>

โฮสต์ Node

สำหรับโฮสต์ node ให้ใช้ไฟล์การอนุมัติเดียวกันบน node นั้นแทน:

openclaw approvals set --node <id|name|ip> --stdin <<'EOF'{  version: 1,  defaults: {    security: "full",    ask: "off",    askFallback: "full"  }}EOF

ทางลัดเฉพาะเซสชัน

• /exec security=full ask=off เปลี่ยนเฉพาะเซสชันปัจจุบันเท่านั้น
• /elevated full เป็นทางลัดแบบ break-glass ที่ข้ามการอนุมัติ exec เฉพาะเมื่อ ทั้งนโยบายที่ร้องขอและไฟล์ approvals ของโฮสต์แปลงค่าได้เป็น security: "full" และ ask: "off" ไฟล์โฮสต์ที่เข้มงวดกว่า เช่น ask: "always" ยังคงแสดงพรอมป์

หากไฟล์ approvals ของโฮสต์ยังเข้มงวดกว่าคอนฟิก นโยบายโฮสต์ที่เข้มงวดกว่า ยังคงมีผลเหนือกว่า

รายการอนุญาต (ต่อเอเจนต์)

รายการอนุญาตเป็นแบบ ต่อเอเจนต์ หากมีหลายเอเจนต์ ให้สลับเอเจนต์ ที่คุณกำลังแก้ไขในแอป macOS รูปแบบเป็นการจับคู่แบบ glob

รูปแบบสามารถเป็น glob ของพาธไบนารีที่แปลงค่าแล้ว หรือ glob ของชื่อคำสั่งล้วน ชื่อล้วนจะจับคู่เฉพาะคำสั่งที่เรียกผ่าน PATH ดังนั้น rg จึงจับคู่กับ /opt/homebrew/bin/rg ได้เมื่อคำสั่งคือ rg แต่ ไม่ จับคู่กับ ./rg หรือ /tmp/rg ใช้ glob ของพาธเมื่อคุณต้องการเชื่อถือไบนารีในตำแหน่งเฉพาะหนึ่งแห่ง

รายการ agents.default เดิมจะถูกย้ายไปเป็น agents.main เมื่อโหลด เชนเชลล์ เช่น echo ok && pwd ยังคงต้องให้ทุกเซกเมนต์ระดับบนสุด ผ่านกฎรายการอนุญาต

ตัวอย่าง:

• rg
• ~/Projects/**/bin/peekaboo
• ~/.local/bin/*
• /opt/homebrew/bin/rg

การจำกัดอาร์กิวเมนต์ด้วย argPattern

เพิ่ม argPattern เมื่อรายการอนุญาตควรจับคู่กับไบนารีและ รูปแบบอาร์กิวเมนต์เฉพาะ OpenClaw ประเมิน regular expression กับอาร์กิวเมนต์คำสั่งที่แยกวิเคราะห์แล้ว โดยไม่รวมโทเค็น executable (argv[0]) สำหรับรายการที่เขียนด้วยมือ อาร์กิวเมนต์จะถูกเชื่อมด้วย เว้นวรรคเดียว ดังนั้นให้ยึด pattern ด้วย anchor เมื่อคุณต้องการการจับคู่แบบตรงทั้งหมด

{  "version": 1,  "agents": {    "main": {      "allowlist": [        {          "pattern": "python3",          "argPattern": "^safe\\.py$"        }      ]    }  }}

รายการนั้นอนุญาต python3 safe.py; python3 other.py จะไม่ตรงกับรายการอนุญาต หากมีรายการแบบพาธล้วนสำหรับไบนารีเดียวกันอยู่ด้วย อาร์กิวเมนต์ที่ไม่ตรงกัน ยังสามารถ fallback ไปยังรายการแบบพาธล้วนนั้นได้ ละเว้นรายการแบบพาธล้วน เมื่อเป้าหมายคือจำกัดไบนารีให้ใช้ได้เฉพาะกับอาร์กิวเมนต์ที่ประกาศไว้

รายการที่บันทึกโดยโฟลว์การอนุมัติสามารถใช้รูปแบบตัวคั่นภายในสำหรับ การจับคู่ argv แบบตรงทั้งหมด ควรใช้ UI หรือโฟลว์การอนุมัติเพื่อสร้าง รายการเหล่านั้นใหม่ แทนการแก้ไขค่าที่เข้ารหัสด้วยมือ หาก OpenClaw ไม่สามารถ แยกวิเคราะห์ argv สำหรับเซกเมนต์คำสั่งได้ รายการที่มี argPattern จะไม่จับคู่

แต่ละรายการอนุญาตรองรับ:

อนุญาต CLI ของ Skills อัตโนมัติ

เมื่อเปิดใช้ อนุญาต CLI ของ Skills อัตโนมัติ executable ที่อ้างอิงโดย Skills ที่รู้จักจะถูกถือว่าอยู่ในรายการอนุญาตบน Node (Node ของ macOS หรือโฮสต์ Node แบบ headless) การทำงานนี้ใช้ skills.bins ผ่าน Gateway RPC เพื่อดึง รายการ bin ของ skill ปิดใช้งานตัวเลือกนี้หากคุณต้องการรายการอนุญาตแบบแมนนวลที่เข้มงวด

Safe bins และการส่งต่อการอนุมัติ

สำหรับ safe bins (fast-path แบบ stdin-only), รายละเอียดการผูก interpreter และ วิธีส่งต่อพรอมป์การอนุมัติไปยัง Slack/Discord/Telegram (หรือเรียกใช้เป็น ไคลเอนต์การอนุมัติแบบ native) โปรดดู การอนุมัติ exec - ขั้นสูง

การแก้ไขใน Control UI

ใช้การ์ด Control UI → Nodes → Exec approvals เพื่อแก้ไขค่าเริ่มต้น, การ override ต่อเอเจนต์ และรายการอนุญาต เลือกขอบเขต (ค่าเริ่มต้นหรือเอเจนต์), ปรับนโยบาย, เพิ่ม/ลบรูปแบบรายการอนุญาต แล้วกด Save UI แสดงเมทาดาทาการใช้งานครั้งล่าสุดต่อ pattern เพื่อให้คุณรักษารายการให้เป็นระเบียบได้

ตัวเลือกเป้าหมายเลือก Gateway (การอนุมัติภายในเครื่อง) หรือ Node Node ต้องประกาศ system.execApprovals.get/set (แอป macOS หรือ โฮสต์ Node แบบ headless) หาก Node ยังไม่ได้ประกาศ exec approvals ให้แก้ไขไฟล์ approvals ภายในเครื่องของ Node โดยตรง

CLI: openclaw approvals รองรับการแก้ไข Gateway หรือ Node - ดู CLI การอนุมัติ

โฟลว์การอนุมัติ

เมื่อจำเป็นต้องมีพรอมป์ Gateway จะกระจาย exec.approval.requested ไปยังไคลเอนต์ผู้ปฏิบัติงาน Control UI และแอป macOS จะแก้ไขคำขอนั้นผ่าน exec.approval.resolve จากนั้น Gateway จะส่งต่อคำขอ ที่อนุมัติแล้วไปยังโฮสต์ Node

สำหรับ host=node คำขออนุมัติจะมี payload systemRunPlan แบบ canonical Gateway ใช้แผนนั้นเป็นบริบทคำสั่ง/cwd/เซสชันที่มีอำนาจตัดสิน เมื่อส่งต่อคำขอ system.run ที่อนุมัติแล้ว

สิ่งนี้สำคัญต่อ latency ของการอนุมัติแบบ async:

• พาธ exec ของ Node เตรียมแผน canonical หนึ่งรายการไว้ล่วงหน้า
• ระเบียนการอนุมัติเก็บแผนนั้นและเมทาดาทาการผูกของแผน
• เมื่ออนุมัติแล้ว การเรียก system.run สุดท้ายที่ถูกส่งต่อจะใช้แผนที่เก็บไว้ซ้ำ แทนการเชื่อถือการแก้ไขภายหลังจากผู้เรียก
• หากผู้เรียกเปลี่ยน command, rawCommand, cwd, agentId หรือ sessionKey หลังจากสร้างคำขออนุมัติแล้ว Gateway จะปฏิเสธการรันที่ส่งต่อว่าเป็นการอนุมัติไม่ตรงกัน

เหตุการณ์ระบบ

วงจรชีวิตของ exec จะแสดงเป็นข้อความระบบ:

• Exec running (เฉพาะเมื่อคำสั่งเกิน threshold การแจ้งว่ากำลังรัน)
• Exec finished

ข้อความเหล่านี้จะถูกโพสต์ไปยังเซสชันของเอเจนต์หลังจาก Node รายงานเหตุการณ์ การอนุมัติ exec ที่ถูกปฏิเสธถือเป็นสถานะสิ้นสุดสำหรับคำสั่งโฮสต์เอง: คำสั่ง จะไม่ถูกรัน สำหรับการอนุมัติ async ของเอเจนต์หลักที่มีเซสชันต้นทาง OpenClaw จะโพสต์การปฏิเสธกลับเข้าไปในเซสชันนั้นเป็น followup ภายใน เพื่อให้ เอเจนต์หยุดรอคำสั่ง async และหลีกเลี่ยงการซ่อมแซมผลลัพธ์ที่หายไป หากไม่มีเซสชันหรือไม่สามารถกลับมาใช้เซสชันต่อได้ OpenClaw ยังคงสามารถ รายงานการปฏิเสธแบบกระชับไปยังผู้ปฏิบัติงานหรือเส้นทางแชทโดยตรงได้ การปฏิเสธสำหรับ เซสชัน subagent จะไม่ถูกโพสต์กลับเข้าไปใน subagent การอนุมัติ exec ที่โฮสต์โดย Gateway จะปล่อยเหตุการณ์วงจรชีวิตเดียวกันเมื่อ คำสั่งเสร็จสิ้น (และอาจปล่อยเมื่อรันนานกว่า threshold) exec ที่ถูกควบคุมด้วยการอนุมัติจะใช้ id การอนุมัติซ้ำเป็น runId ใน ข้อความเหล่านี้เพื่อให้เชื่อมโยงกันได้ง่าย

พฤติกรรมเมื่อการอนุมัติถูกปฏิเสธ

เมื่อการอนุมัติ exec แบบ async ถูกปฏิเสธ OpenClaw จะถือว่าคำสั่งโฮสต์ สิ้นสุดแล้วและ fail-closed สำหรับเซสชันเอเจนต์หลัก การปฏิเสธจะถูกส่งเป็น followup ภายในเซสชันที่บอกเอเจนต์ว่าคำสั่ง async ไม่ได้ถูกรัน วิธีนี้รักษาความต่อเนื่องของ transcript โดยไม่เปิดเผยผลลัพธ์คำสั่งที่ล้าสมัย หาก การส่งไปยังเซสชันไม่พร้อมใช้งาน OpenClaw จะ fallback ไปยังการปฏิเสธแบบกระชับสำหรับผู้ปฏิบัติงานหรือ แชทโดยตรงเมื่อมีเส้นทางที่ปลอดภัย

ผลที่ตามมา

• full มีอำนาจสูง; ควรใช้รายการอนุญาตเมื่อเป็นไปได้
• ask ทำให้คุณยังอยู่ในวงจรตัดสินใจ ขณะเดียวกันก็ยังอนุมัติได้รวดเร็ว
• รายการอนุญาตต่อเอเจนต์ช่วยป้องกันไม่ให้การอนุมัติของเอเจนต์หนึ่งรั่วไปยังอีกเอเจนต์
• การอนุมัติมีผลเฉพาะกับคำขอ host exec จาก ผู้ส่งที่ได้รับอนุญาต เท่านั้น ผู้ส่งที่ไม่ได้รับอนุญาตไม่สามารถออกคำสั่ง /exec
• /exec security=full เป็นความสะดวกระดับเซสชันสำหรับผู้ปฏิบัติงานที่ได้รับอนุญาต และข้ามการอนุมัติโดยเจตนา หากต้องการบล็อก host exec อย่างเด็ดขาด ให้ตั้งค่า approvals security เป็น deny หรือปฏิเสธเครื่องมือ exec ผ่านนโยบายเครื่องมือ

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