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

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

policy ที่มีผลจริงคือค่าที่ เข้มงวดกว่า ระหว่าง tools.exec.* กับค่าเริ่มต้นของการอนุมัติ หากละเว้นฟิลด์การอนุมัติไว้ จะใช้ค่าจาก tools.exec แทน การ exec บนโฮสต์ยังใช้สถานะการอนุมัติภายในเครื่องนั้นด้วย - ค่า ask: "always" แบบเฉพาะโฮสต์ใน ~/.openclaw/exec-approvals.json จะยัง แสดงพรอมป์ต่อไป แม้ค่าเริ่มต้นของเซสชันหรือคอนฟิกจะขอ ask: "on-miss" ก็ตาม

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

คำสั่ง	สิ่งที่แสดง
`openclaw approvals get` / `--gateway` / `--node <id\|name\|ip>`	policy ที่ร้องขอ แหล่งที่มาของ policy บนโฮสต์ และผลลัพธ์ที่มีผลจริง
`openclaw exec-policy show`	มุมมองที่ผสานแล้วของเครื่องภายในเครื่อง
`openclaw exec-policy set` / `preset`	ซิงโครไนซ์ policy ที่ร้องขอภายในเครื่องกับไฟล์การอนุมัติของโฮสต์ภายในเครื่องในขั้นตอนเดียว

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

ไคลเอนต์อนุมัติแบบแชตเนทีฟสามารถใส่ตัวช่วยเฉพาะช่องทางไว้ในข้อความอนุมัติที่รอดำเนินการได้ ตัวอย่างเช่น Matrix ใส่ทางลัดด้วย reaction (✅ อนุญาตครั้งเดียว, ❌ ปฏิเสธ, ♾️ อนุญาตเสมอ) ในขณะที่ยังคงใส่ คำสั่ง /approve ... ไว้ในข้อความเป็น fallback

ใช้ที่ใด

การอนุมัติ 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`

security

"deny" | "allowlist" | "full"

deny - บล็อกคำขอ exec บนโฮสต์ทั้งหมด
allowlist - อนุญาตเฉพาะคำสั่งที่อยู่ในรายการอนุญาต
full - อนุญาตทุกอย่าง (เทียบเท่า elevated)

`exec.ask`

ask

"off" | "on-miss" | "always"

off - ไม่แสดงพรอมป์
on-miss - แสดงพรอมป์เฉพาะเมื่อรายการอนุญาตไม่ตรงกัน
always - แสดงพรอมป์ทุกคำสั่ง ความเชื่อถือถาวรแบบ allow-always ไม่ ระงับพรอมป์เมื่อโหมด ask ที่มีผลจริงคือ always

`askFallback`

askFallback

"deny" | "allowlist" | "full"

การตัดสินเมื่อจำเป็นต้องแสดงพรอมป์แต่ไม่มี UI ที่เข้าถึงได้

deny - บล็อก
allowlist - อนุญาตเฉพาะเมื่อรายการอนุญาตตรงกัน
full - อนุญาต

`tools.exec.strictInlineEval`

strictInlineEval

boolean

เมื่อเป็น true OpenClaw จะถือรูปแบบ inline code-eval ว่าต้องผ่านการอนุมัติเท่านั้น แม้ binary ของ interpreter เองจะอยู่ในรายการอนุญาตก็ตาม เป็น defense-in-depth สำหรับ loader ของ interpreter ที่ไม่สามารถ map กับ operand ไฟล์ที่เสถียรหนึ่งไฟล์ได้อย่างชัดเจน

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

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`

commandHighlighting

boolean

default:"false"

ควบคุมเฉพาะการนำเสนอในพรอมป์การอนุมัติ exec เมื่อเปิดใช้ OpenClaw อาจแนบช่วงคำสั่งที่ได้จาก parser เพื่อให้พรอมป์อนุมัติบน Web สามารถไฮไลต์โทเคนคำสั่งได้ ตั้งค่าเป็น true เพื่อเปิดใช้ การไฮไลต์ข้อความคำสั่ง

การตั้งค่านี้ ไม่ เปลี่ยน 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 เป็นพฤติกรรมโฮสต์เริ่มต้น เว้นแต่คุณจะทำให้เข้มงวดขึ้นอย่างชัดเจน:

ชั้น	การตั้งค่า YOLO
`tools.exec.security`	`full` บน `gateway`/`node`
`tools.exec.ask`	`off`
`Host` askFallback`	`full`

ข้อแตกต่างสำคัญ:

tools.exec.host=auto เลือกว่า exec รัน ที่ใด: sandbox เมื่อพร้อมใช้งาน มิฉะนั้นเป็น Gateway
YOLO เลือกว่า exec บนโฮสต์ได้รับการอนุมัติ อย่างไร: security=full รวมกับ ask=off
ในโหมด YOLO OpenClaw ไม่ เพิ่ม gate การอนุมัติการอำพรางคำสั่งด้วย heuristic หรือชั้นการปฏิเสธก่อนรันสคริปต์แยกต่างหากไว้เหนือ policy exec บนโฮสต์ที่กำหนดค่าไว้
auto ไม่ทำให้การ route ไปยัง Gateway เป็น override ฟรีจากเซสชันที่อยู่ใน sandbox คำขอ host=node ต่อครั้งได้รับอนุญาตจาก auto; host=gateway ได้รับอนุญาตจาก auto เฉพาะเมื่อไม่มี runtime ของ sandbox ที่ทำงานอยู่ สำหรับค่าเริ่มต้นแบบไม่ใช่ auto ที่เสถียร ให้ตั้งค่า tools.exec.host หรือใช้ /exec host=... อย่างชัดเจน

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

ตั้งค่า policy คอนฟิกที่ร้องขอ

OC_I18N_900002

ปรับไฟล์การอนุมัติของโฮสต์ให้ตรงกัน

OC_I18N_900003

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

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

ข้อจำกัดเฉพาะภายในเครื่อง:

openclaw exec-policy ไม่ซิงโครไนซ์การอนุมัติของ Node
openclaw exec-policy set --host node ถูกปฏิเสธ
การอนุมัติ exec ของ Node ถูกดึงจาก Node ขณะรันไทม์ ดังนั้นการอัปเดตที่มุ่งไปยัง Node ต้องใช้ openclaw approvals --node ...

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

/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 แต่ละรายการรองรับ:

ฟิลด์	ความหมาย
`pattern`	glob ของพาธไบนารีที่ resolve แล้ว หรือ glob ของชื่อคำสั่งแบบเปล่า
`argPattern`	regex ของ argv แบบไม่บังคับ; รายการที่ละไว้จะอิงเฉพาะพาธ
`id`	UUID คงที่ที่ใช้สำหรับตัวตนใน UI
`source`	แหล่งที่มาของรายการ เช่น `allow-always`
`commandText`	ข้อความคำสั่งที่บันทึกไว้เมื่อโฟลว์การอนุมัติสร้างรายการ
`lastUsedAt`	timestamp ที่ใช้ล่าสุด
`lastUsedCommand`	คำสั่งล่าสุดที่ตรงกัน
`lastResolvedPath`	พาธไบนารีล่าสุดที่ resolve ได้

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

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

นี่คือ allowlist เพื่อความสะดวกแบบนัย ซึ่งแยกจากรายการ allowlist พาธที่กำหนดเอง
มีไว้สำหรับสภาพแวดล้อมของผู้ปฏิบัติการที่เชื่อถือได้ ซึ่ง Gateway และ Node อยู่ในขอบเขตความเชื่อถือเดียวกัน
หากคุณต้องการความเชื่อถือแบบระบุชัดอย่างเข้มงวด ให้คง autoAllowSkills: false ไว้และใช้เฉพาะรายการ 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

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

การอนุมัติ Exec - ขั้นสูง

Bin ที่ปลอดภัย, การผูก interpreter และการส่งต่อการอนุมัติไปยังแชต

Tool Exec

Tool สำหรับเรียกใช้คำสั่ง shell

โหมด Elevated

เส้นทาง break-glass ที่ข้ามการอนุมัติด้วย

Sandboxing

โหมด sandbox และการเข้าถึง workspace

ความปลอดภัย

โมเดลความปลอดภัยและการเพิ่มความแข็งแกร่ง

Sandbox เทียบกับนโยบาย tool เทียบกับ elevated

ควรใช้การควบคุมแต่ละแบบเมื่อใด

Skills

ลักษณะการอนุญาตอัตโนมัติที่อิงกับ Skills

Overview

Plugins

Bundled plugin guides

Building plugins

Skills

Automation

Tools

Agent coordination

Documentation Index

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

​ใช้ที่ใด

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

​การแยกบน macOS

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

​ตัวปรับ policy

​exec.security

​exec.ask

​askFallback

​tools.exec.strictInlineEval

​tools.exec.commandHighlighting

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

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

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

​โฮสต์ Node

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

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

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

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

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

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

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

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

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

​ผลกระทบ

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

การอนุมัติ Exec - ขั้นสูง

Tool Exec

โหมด Elevated

Sandboxing

ความปลอดภัย

Sandbox เทียบกับนโยบาย tool เทียบกับ elevated

Skills

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

ใช้ที่ใด

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

การแยกบน macOS

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

ตัวปรับ policy

`exec.security`

`exec.ask`

`askFallback`

`tools.exec.strictInlineEval`

`tools.exec.commandHighlighting`

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

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

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

โฮสต์ Node

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

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

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

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

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

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

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

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

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

ผลกระทบ

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