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

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

การตรวจสอบ policy ที่มีผลจริง

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

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

ใช้ที่ใด

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

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

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

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

การแยกบน macOS

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

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

การอนุมัติอยู่ในไฟล์ JSON ภายในเครื่องบนโฮสต์ที่ดำเนินการ:

~/.openclaw/exec-approvals.json

ตัวอย่าง 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"        }      ]    }  }}

ตัวปรับ policy

exec.security

exec.ask

askFallback

tools.exec.strictInlineEval

ตัวอย่างที่โหมดเข้มงวดตรวจจับได้:

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

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

tools.exec.commandHighlighting

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

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

หากคุณต้องการให้ exec บนโฮสต์รันโดยไม่มีพรอมป์การอนุมัติ คุณต้องเปิด policy ทั้งสอง ชั้น - policy exec ที่ร้องขอในคอนฟิก OpenClaw (tools.exec.*) และ policy การอนุมัติแบบเฉพาะโฮสต์ใน ~/.openclaw/exec-approvals.json

YOLO เป็นพฤติกรรมโฮสต์เริ่มต้น เว้นแต่คุณจะทำให้เข้มงวดขึ้นอย่างชัดเจน:

provider ที่มี CLI รองรับและเปิดเผยโหมดสิทธิ์แบบ noninteractive ของตนเอง สามารถทำตาม policy นี้ได้ Claude CLI จะเพิ่ม --permission-mode bypassPermissions เมื่อ policy exec ที่ OpenClaw ร้องขอ เป็น YOLO ให้ override พฤติกรรม backend นั้นด้วยอาร์กิวเมนต์ Claude ที่ชัดเจน ภายใต้ agents.defaults.cliBackends.claude-cli.args / resumeArgs - เช่น --permission-mode default, acceptEdits หรือ bypassPermissions

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

การตั้งค่า "ไม่ต้องแสดงพรอมป์" แบบถาวรบนโฮสต์ Gateway

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

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

• tools.exec.host/security/ask ภายในเครื่อง
• ค่าเริ่มต้นของ ~/.openclaw/exec-approvals.json ภายในเครื่อง

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

โฮสต์ Node

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

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

• /exec security=full ask=off เปลี่ยนเฉพาะเซสชันปัจจุบัน
• /elevated full เป็นทางลัดแบบ break-glass ที่ข้ามการอนุมัติ exec สำหรับเซสชันนั้นด้วย

หากไฟล์การอนุมัติของโฮสต์ยังเข้มงวดกว่าคอนฟิก policy ของโฮสต์ที่เข้มงวดกว่า ก็ยังเป็นฝ่ายชนะ

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

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

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

รายการ agents.default แบบ legacy จะถูก migrate เป็น agents.main เมื่อโหลด เชนของ shell เช่น echo ok && pwd ยังต้องให้ทุก segment ระดับบนสุด เป็นไปตามกฎรายการอนุญาต

ตัวอย่าง:

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

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

เพิ่ม argPattern เมื่อรายการในรายการอนุญาตควรตรงกับ binary และ รูปแบบอาร์กิวเมนต์ที่เฉพาะเจาะจง OpenClaw ประเมิน regular expression กับอาร์กิวเมนต์คำสั่งที่ parse แล้ว โดยไม่รวมโทเคน executable (argv[0]) สำหรับรายการที่เขียนเอง อาร์กิวเมนต์จะถูก join ด้วย ช่องว่างเดียว ดังนั้นให้ anchor pattern เมื่อคุณต้องการการจับคู่ที่ตรงเป๊ะ OC_I18N_900006 รายการนั้นอนุญาต python3 safe.py; python3 other.py เป็นการไม่ตรงกับรายการอนุญาต หากมีรายการเฉพาะพาธสำหรับ binary เดียวกันอยู่ด้วย อาร์กิวเมนต์ที่ไม่ตรงกัน ยังสามารถ fallback ไปยังรายการเฉพาะพาธนั้นได้ ละเว้นรายการเฉพาะพาธเมื่อเป้าหมายคือ การจำกัด binary ให้ใช้ได้เฉพาะอาร์กิวเมนต์ที่ประกาศไว้เท่านั้น

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

รายการ allowlist แต่ละรายการรองรับ:

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

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

Bin ที่ปลอดภัยและการส่งต่อการอนุมัติ

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

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

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

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

CLI: openclaw approvals รองรับการแก้ไข Gateway หรือ Node - ดู Approvals CLI

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

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

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

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

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

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

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

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

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

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

เมื่อการอนุมัติ exec แบบ async ถูกปฏิเสธ OpenClaw จะป้องกันไม่ให้ agent ใช้ output จากการรันก่อนหน้าของคำสั่งเดียวกันใน session นั้นซ้ำ เหตุผลการปฏิเสธจะถูกส่งไปพร้อมคำแนะนำที่ชัดเจนว่าไม่มี output ของคำสั่งให้ใช้ ซึ่งหยุด agent ไม่ให้กล่าวอ้างว่ามี output ใหม่หรือรันคำสั่งที่ถูกปฏิเสธซ้ำโดยใช้ผลลัพธ์เก่าจากการรันก่อนหน้าที่สำเร็จ

ผลกระทบ

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

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