---
read_when:
- การกำหนดค่าการอนุมัติหรือรายการที่อนุญาตสำหรับ exec
- การนำ UX การอนุมัติ exec มาใช้ในแอป macOS
- การตรวจสอบพรอมป์ต์สำหรับการหลบหนีจากแซนด์บ็อกซ์และผลกระทบที่ตามมา
sidebarTitle: Exec approvals
summary: 'การอนุมัติการดำเนินคำสั่งบนโฮสต์: ตัวเลือกนโยบาย รายการที่อนุญาต และเวิร์กโฟลว์แบบ YOLO/เข้มงวด'
title: การอนุมัติการดำเนินการ
x-i18n:
generated_at: "2026-07-19T07:35:28Z"
model: gpt-5.6
postprocess_version: locale-links-v1
prompt_version: 32
provider: openai
source_hash: 4553f129db78cce95bfde7c4a13b95a2282f9d1ab38ba5819a0816a4fd5ea4c6
source_path: tools/exec-approvals.md
workflow: 16
---
การอนุมัติ exec เป็น **กลไกป้องกันของแอปคู่หู / โฮสต์ Node** สำหรับอนุญาตให้เอเจนต์ที่ทำงานใน
แซนด์บ็อกซ์เรียกใช้คำสั่งบนโฮสต์จริง (`gateway` หรือ `node`) คำสั่งจะ
ทำงานเฉพาะเมื่อนโยบาย + รายการอนุญาต + การอนุมัติจากผู้ใช้ (ไม่บังคับ) สอดคล้องกันทั้งหมด
การอนุมัติจะซ้อน **อยู่เหนือนโยบายเครื่องมือ** และการควบคุมสิทธิ์ระดับสูง (elevated
`full` จะข้ามการอนุมัติเหล่านี้)
สำหรับภาพรวมที่จัดตามโหมดของ `deny`, `allowlist`, `ask`, `auto`, `full`,
การแมป Codex Guardian และสิทธิ์ของชุดทดสอบ ACPX โปรดดู
[โหมดสิทธิ์](/th/tools/permission-modes)
นโยบายที่มีผลคือค่าที่ **เข้มงวดกว่า** ระหว่าง `tools.exec.*` กับค่าเริ่มต้นของการอนุมัติ:
การอนุมัติทำได้เพียงเพิ่มความเข้มงวดให้กับ security/ask ที่มาจากการกำหนดค่าเท่านั้น และไม่สามารถ
ผ่อนปรนได้ หากละเว้นฟิลด์การอนุมัติ ระบบจะใช้ค่า `tools.exec`
การเรียกใช้บนโฮสต์ยังใช้สถานะการอนุมัติภายในเครื่องนั้นด้วย โดย `ask: "always"`
เฉพาะโฮสต์ในไฟล์การอนุมัติของโฮสต์ที่เรียกใช้จะยังคงแสดงข้อความถาม แม้ว่าค่าเริ่มต้นของเซสชัน
หรือการกำหนดค่าจะร้องขอ `ask: "on-miss"`
## ขอบเขตการใช้งาน
การอนุมัติ exec จะถูกบังคับใช้ภายในโฮสต์ที่เรียกใช้:
- **โฮสต์ Gateway** -> กระบวนการ `openclaw` บนเครื่อง Gateway
- **โฮสต์ Node** -> ตัวรัน Node (แอปคู่หูบน macOS หรือโฮสต์ Node แบบไม่มีส่วนติดต่อ)
### โมเดลความเชื่อถือ
- ผู้เรียกที่ผ่านการตรวจสอบสิทธิ์โดย Gateway ถือเป็นผู้ดำเนินการที่เชื่อถือได้สำหรับ Gateway นั้น
- Node ที่จับคู่แล้วจะขยายความสามารถของผู้ดำเนินการที่เชื่อถือได้นั้นไปยังโฮสต์ Node
- การอนุมัติช่วยลดความเสี่ยงจากการเรียกใช้โดยไม่ตั้งใจ แต่ **ไม่ใช่** ขอบเขตการตรวจสอบสิทธิ์แยกตามผู้ใช้หรือนโยบายระบบไฟล์แบบอ่านอย่างเดียว
- เมื่อได้รับอนุมัติแล้ว คำสั่งสามารถแก้ไขไฟล์ได้ตามสิทธิ์ของระบบไฟล์บนโฮสต์หรือแซนด์บ็อกซ์ที่เลือก
- การเรียกใช้บนโฮสต์ Node ที่ได้รับอนุมัติจะผูกบริบทการเรียกใช้แบบมาตรฐาน ได้แก่ cwd, argv ที่ตรงทุกประการ, การผูก env เมื่อมี และพาธไฟล์ปฏิบัติการที่ตรึงไว้เมื่อเกี่ยวข้อง
- สำหรับเชลล์สคริปต์และการเรียกไฟล์ผ่านอินเทอร์พรีเตอร์/รันไทม์โดยตรง OpenClaw จะพยายามผูกโอเปอแรนด์ไฟล์ภายในเครื่องที่ระบุได้แน่ชัดหนึ่งไฟล์ด้วย หากไฟล์นั้นเปลี่ยนหลังการอนุมัติแต่ก่อนการเรียกใช้ ระบบจะปฏิเสธการทำงานแทนการเรียกใช้เนื้อหาที่เปลี่ยนไป
- การผูกไฟล์เป็นความพยายามอย่างดีที่สุด ไม่ใช่โมเดลที่ครอบคลุมทุกพาธการโหลดของอินเทอร์พรีเตอร์/รันไทม์ หากไม่สามารถระบุไฟล์ภายในเครื่องที่แน่ชัดได้เพียงหนึ่งไฟล์ OpenClaw จะปฏิเสธการสร้างการเรียกใช้ที่อาศัยการอนุมัติ แทนการอ้างว่าครอบคลุมอย่างสมบูรณ์
### การแยกส่วนบน macOS
- **บริการโฮสต์ Node** ส่งต่อ `system.run` ไปยัง **แอป macOS** ผ่าน IPC ภายในเครื่อง
- **แอป macOS** บังคับใช้การอนุมัติและเรียกใช้คำสั่งในบริบทของ UI
## การตรวจสอบนโยบายที่มีผล
| คำสั่ง | สิ่งที่แสดง |
| ---------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| `openclaw approvals get` / `--gateway` / `--node ` | นโยบายที่ร้องขอ แหล่งที่มาของนโยบายโฮสต์ และผลลัพธ์ที่มีผล |
| `openclaw exec-policy show` | มุมมองแบบรวมของเครื่องภายใน |
| `openclaw exec-policy set` / `preset` | ซิงโครไนซ์นโยบายภายในที่ร้องขอกับไฟล์การอนุมัติของโฮสต์ภายในในขั้นตอนเดียว |
การแทนที่ `/exec` แยกตามเซสชันจะไม่รวมอยู่ด้วย เรียกใช้ `/exec` ในเซสชันที่เกี่ยวข้องเพื่อตรวจสอบค่าเริ่มต้นปัจจุบัน โปรดดู [การแทนที่ของเซสชัน](/th/tools/exec#session-overrides-exec)
ข้อมูลอ้างอิง CLI ฉบับเต็ม (แฟล็ก, เอาต์พุต JSON, การเพิ่ม/ลบรายการอนุญาต): [CLI การอนุมัติ](/th/cli/approvals)
เมื่อขอบเขตภายในร้องขอ `host=node` ระบบ `exec-policy show` จะรายงานว่า
ขอบเขตนั้นจัดการโดย Node ขณะรัน แทนการถือว่าไฟล์การอนุมัติภายใน
เป็นแหล่งข้อมูลจริง
หาก UI ของแอปคู่หู **ไม่พร้อมใช้งาน** คำขอใดก็ตามที่ตามปกติ
ต้องแสดงข้อความถามจะถูกตัดสินด้วย **ค่าทดแทนของ ask** (ค่าเริ่มต้น: `deny`)
ไคลเอนต์อนุมัติสำหรับแชตแบบเนทีฟสามารถเตรียมตัวเลือกเฉพาะช่องทางไว้ใน
ข้อความการอนุมัติที่รอดำเนินการได้ Matrix จะเตรียมทางลัดด้วยรีแอ็กชัน (`✅` อนุญาตหนึ่งครั้ง,
`♾️` อนุญาตเสมอ, `❌` ปฏิเสธ) ขณะที่ยังคงมี `/approve ...` ใน
ข้อความเป็นตัวเลือกสำรอง
## การตั้งค่าและพื้นที่จัดเก็บ
การอนุมัติจะอยู่ในไฟล์ JSON ภายในโฮสต์ที่เรียกใช้ เมื่อกำหนด
`OPENCLAW_STATE_DIR` ไฟล์จะอยู่ตามไดเรกทอรีสถานะนั้น
มิฉะนั้นจะใช้ไดเรกทอรีสถานะเริ่มต้นของ OpenClaw:
```text
$OPENCLAW_STATE_DIR/exec-approvals.json
# มิฉะนั้น
~/.openclaw/exec-approvals.json
```
ซ็อกเก็ตการอนุมัติเริ่มต้นใช้รากเดียวกัน:
`$OPENCLAW_STATE_DIR/exec-approvals.sock` หรือ
`~/.openclaw/exec-approvals.sock` เมื่อไม่ได้กำหนดตัวแปร
ไดเรกทอรีสถานะเป็นขอบเขตความเชื่อถือที่แยกจากกัน เมื่อ `OPENCLAW_STATE_DIR`
ชี้ไปยังตำแหน่งอื่น OpenClaw จะไม่เคยนำเข้าหรือเก็บถาวร
`~/.openclaw/exec-approvals.json`; ให้กำหนดค่าการอนุมัติแยกต่างหากสำหรับ
ไดเรกทอรีสถานะแบบกำหนดเอง Doctor จะนำเข้า
`plugin-binding-approvals.json` แบบเดิมเฉพาะเมื่อเป็นของไดเรกทอรีสถานะ
ที่ใช้งานอยู่เท่านั้น
ตัวอย่างสคีมา:
```json
{
"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",
"lastUsedAt": 1737150000000,
"lastUsedCommand": "rg -n TODO",
"lastResolvedPath": "/Users/user/Projects/.../bin/rg"
}
]
}
}
}
```
## ตัวควบคุมนโยบาย
### `tools.exec.mode`
`tools.exec.mode` เป็นพื้นผิวนโยบายที่ปรับเป็นมาตรฐานซึ่งแนะนำให้ใช้สำหรับ exec บนโฮสต์:
| ค่า | ลักษณะการทำงาน |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `deny` | บล็อก exec บนโฮสต์ |
| `allowlist` | เรียกใช้เฉพาะคำสั่งในรายการอนุญาตโดยไม่ถาม |
| `ask` | ใช้นโยบายรายการอนุญาตและถามเมื่อไม่พบรายการที่ตรงกัน |
| `auto` | ใช้นโยบายรายการอนุญาต เรียกใช้รายการที่ตรงกันแบบกำหนดผลลัพธ์ได้โดยตรง และส่งรายการที่ไม่ผ่านการอนุมัติไปยังผู้รีวิวอัตโนมัติแบบเนทีฟของ OpenClaw ก่อนใช้เส้นทางการอนุมัติจากมนุษย์เป็นตัวเลือกสำรอง |
| `full` | เรียกใช้ exec บนโฮสต์โดยไม่แสดงข้อความขออนุมัติ |
`tools.exec.security` / `tools.exec.ask` แบบเดิมยังคงรองรับและยัง
มีผลในทุกขอบเขตที่ไม่ได้กำหนด `mode`
### `exec.security`
- `deny` - บล็อกคำขอ exec บนโฮสต์ทั้งหมด
- `allowlist` - อนุญาตเฉพาะคำสั่งในรายการอนุญาต
- `full` - อนุญาตทุกอย่าง (เทียบเท่ากับ elevated)
ค่าเริ่มต้นคือ `full` สำหรับโฮสต์ Gateway/Node ส่วนโฮสต์ `sandbox` จะมีค่าเริ่มต้นเป็น
`deny` แทน
### `exec.ask`
นโยบาย ask ที่กำหนดค่าไว้สำหรับ exec บนโฮสต์ ควบคุมลักษณะพื้นฐานของ
ข้อความขออนุมัติจาก `tools.exec.ask` และค่าเริ่มต้นของการอนุมัติโฮสต์
ค่าเริ่มต้นคือ `off` พารามิเตอร์เครื่องมือ `ask` แยกตามการเรียก (ดู
[เครื่องมือ Exec](/th/tools/exec#parameters)) ทำได้เพียงเพิ่มความเข้มงวดให้กับค่าพื้นฐานนั้น และ
การเรียกโมเดลที่มาจากช่องทางจะไม่สนใจพารามิเตอร์นี้เมื่อ ask ของโฮสต์ที่มีผลเป็น `off`
- `off` - ไม่แสดงข้อความถาม
- `on-miss` - แสดงข้อความถามเฉพาะเมื่อไม่ตรงกับรายการอนุญาต
- `always` - แสดงข้อความถามสำหรับทุกคำสั่ง ความเชื่อถือแบบถาวร `allow-always` จะ **ไม่** ระงับข้อความถามเมื่อโหมด ask ที่มีผลเป็น `always`
### `askFallback`
การตัดสินเมื่อจำเป็นต้องแสดงข้อความถามแต่ไม่สามารถเข้าถึง UI ได้ (หรือ
ข้อความถามหมดเวลา) ค่าเริ่มต้นคือ `deny` เมื่อละเว้น
- `deny` - บล็อก
- `allowlist` - อนุญาตเฉพาะเมื่อตรงกับรายการอนุญาต
- `full` - อนุญาต
### `tools.exec.strictInlineEval`
เมื่อ `true` ให้ถือว่ารูปแบบการประเมินโค้ดแบบอินไลน์ต้องได้รับการอนุมัติเท่านั้น แม้ว่า
ไบนารีอินเทอร์พรีเตอร์จะอยู่ในรายการอนุญาต เป็นการป้องกันเชิงลึกสำหรับ
ตัวโหลดอินเทอร์พรีเตอร์ที่ไม่สามารถแมปกับโอเปอแรนด์ไฟล์ที่เสถียรหนึ่งรายการได้อย่างชัดเจน
ตัวอย่างที่โหมดเข้มงวดตรวจจับได้: `python -c`, `node -e`/`--eval`/`-p`,
`ruby -e`, `perl -e`/`-E`, `php -r`, `lua -e`, `osascript -e` (รวมถึงรูปแบบอินไลน์
`awk`, `sed`, `make`, `find -exec` และ `xargs`)
ในโหมดเข้มงวด คำสั่งเหล่านี้ต้องได้รับการอนุมัติจากผู้รีวิวหรือการอนุมัติโดยชัดแจ้ง เมื่อใช้
`tools.exec.mode: "auto"` ผู้รีวิวอาจอนุญาตการเรียกใช้ที่มีความเสี่ยงต่ำหนึ่งครั้งเมื่อ
คำสั่งมีแผนที่บังคับใช้ได้ มิฉะนั้น OpenClaw จะถามมนุษย์
การอนุมัติคำสั่ง `Codex app-server` ที่ไปถึงตัวเลือกสำรองของผู้รีวิวจะถาม
มนุษย์ เนื่องจากคำขออนุมัติของคำสั่งเหล่านั้นไม่ได้เปิดเผยไฟล์ปฏิบัติการที่ผ่านการแก้ไขพาธและบังคับใช้ได้
`allow-always` จะไม่บันทึกรายการอนุญาตใหม่สำหรับคำสั่งประเมินผลแบบอินไลน์
### `tools.exec.commandHighlighting`
ใช้เพื่อการนำเสนอเท่านั้น: เมื่อเปิดใช้งาน OpenClaw อาจแนบ
ช่วงคำสั่งที่ได้จากตัวแยกวิเคราะห์ เพื่อให้ข้อความขออนุมัติบนเว็บสามารถเน้นโทเค็นคำสั่งได้ การตั้งค่านี้
**ไม่** เปลี่ยน `security`, `ask`, การจับคู่รายการอนุญาต, ลักษณะการทำงานของ
การประเมินแบบอินไลน์ที่เข้มงวด, การส่งต่อการอนุมัติ หรือการเรียกใช้คำสั่ง
กำหนดแบบส่วนกลางภายใต้ `tools.exec.commandHighlighting` หรือแยกตามเอเจนต์ภายใต้
`agents.list[].tools.exec.commandHighlighting`
## โหมด YOLO (ไม่ต้องอนุมัติ)
หากต้องการเรียกใช้ exec บนโฮสต์โดยไม่มีข้อความขออนุมัติ ให้เปิดนโยบาย **ทั้งสอง** ชั้น:
นโยบาย exec ที่ร้องขอในการกำหนดค่า OpenClaw (`tools.exec.*`) **และ**
นโยบายการอนุมัติเฉพาะโฮสต์ในไฟล์การอนุมัติของโฮสต์ที่เรียกใช้
`askFallback` ที่ละเว้นจะมีค่าเริ่มต้นเป็น `deny` กำหนด `askFallback` ของโฮสต์เป็น `full`
อย่างชัดแจ้ง เมื่อข้อความขออนุมัติที่ไม่มี UI ควรใช้การอนุญาตเป็นตัวเลือกสำรอง
| ชั้น | การตั้งค่า YOLO |
| --------------------- | -------------------------- |
| `tools.exec.security` | `full` บน `gateway`/`node` |
| `tools.exec.ask` | `off` |
| `askFallback` ของโฮสต์ | `full` |
**ข้อแตกต่างที่สำคัญ:**
- `tools.exec.host=auto` เลือกว่า exec จะทำงาน **ที่ใด**: ใน sandbox เมื่อพร้อมใช้งาน มิฉะนั้นจะทำงานบน Gateway
- YOLO เลือกว่า exec บนโฮสต์จะได้รับการอนุมัติ **อย่างไร**: `security=full` ร่วมกับ `ask=off`
- YOLO **ไม่** เพิ่มเกตการอนุมัติคำสั่งที่ตรวจจับการทำให้อ่านเข้าใจยากด้วยฮิวริสติก หรือชั้นปฏิเสธการตรวจสอบสคริปต์ล่วงหน้าแยกต่างหาก นอกเหนือจากนโยบาย exec บนโฮสต์ที่กำหนดค่าไว้
- `auto` ไม่ได้ทำให้การกำหนดเส้นทางไปยัง Gateway กลายเป็นการแทนที่ที่ทำได้อย่างอิสระจากเซสชันใน sandbox คำขอ `host=node` ต่อการเรียกหนึ่งครั้งได้รับอนุญาตจาก `auto`; ส่วน `host=gateway` ได้รับอนุญาตจาก `auto` เฉพาะเมื่อไม่มีรันไทม์ sandbox ที่ทำงานอยู่ สำหรับค่าเริ่มต้นแบบไม่อัตโนมัติที่คงที่ ให้ตั้งค่า `tools.exec.host` หรือใช้ `/exec host=...` อย่างชัดเจน
ผู้ให้บริการที่ใช้ CLI และมีโหมดสิทธิ์แบบไม่โต้ตอบของตนเอง
สามารถปฏิบัติตามนโยบายนี้ได้ Claude CLI จะเพิ่ม
`--permission-mode bypassPermissions` เมื่อนโยบาย exec ที่มีผลของ OpenClaw
เป็น YOLO สำหรับเซสชัน Claude แบบสดที่ OpenClaw จัดการ นโยบาย exec
ที่มีผลของ OpenClaw จะมีอำนาจเหนือกว่าโหมดสิทธิ์ดั้งเดิมของ Claude:
YOLO จะปรับการเปิดใช้งานแบบสดเป็น `--permission-mode bypassPermissions` และ
นโยบาย exec ที่มีผลแบบจำกัดจะปรับการเปิดใช้งานแบบสดเป็น
`--permission-mode default` แม้ว่าอาร์กิวเมนต์ดิบของแบ็กเอนด์ Claude จะระบุโหมดอื่นก็ตาม
หากต้องการการตั้งค่าที่รัดกุมยิ่งขึ้น ให้ปรับนโยบาย exec ของ OpenClaw กลับเป็น
`allowlist` / `on-miss` หรือ `deny`
### การตั้งค่า "ไม่ต้องถาม" แบบถาวรสำหรับโฮสต์ Gateway
```bash
openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off
openclaw gateway restart
```
```bash
openclaw approvals set --stdin <<'EOF'
{
version: 1,
defaults: {
security: "full",
ask: "off",
askFallback: "full"
}
}
EOF
```
### ทางลัดภายในเครื่อง
```bash
openclaw exec-policy preset yolo
```
อัปเดตทั้ง `tools.exec.host/security/ask` ภายในเครื่องและค่าเริ่มต้นของไฟล์การอนุมัติ
ภายในเครื่อง (รวมถึง `askFallback: "full"`) โดยตั้งใจให้มีผล
เฉพาะภายในเครื่อง หากต้องการเปลี่ยนการอนุมัติของโฮสต์ Gateway หรือโฮสต์ Node จากระยะไกล ให้ใช้
`openclaw approvals set --gateway` หรือ `openclaw approvals set --node
`
พรีเซ็ตในตัวอื่น ๆ ได้แก่ `cautious` (`host=gateway`, `security=allowlist`,
`ask=on-miss`, `askFallback=deny`) และ `deny-all` (`host=gateway`,
`security=deny`, `ask=off`, `askFallback=deny`) ใช้ในลักษณะเดียวกัน:
`openclaw exec-policy preset cautious`
หากต้องการตั้งค่าแต่ละฟิลด์แทนพรีเซ็ตทั้งหมด ให้ใช้
`openclaw exec-policy set --host --security
--ask --ask-fallback
` พร้อมชุดย่อยใด ๆ ของแฟล็กเหล่านั้น
### โฮสต์ Node
ใช้ไฟล์การอนุมัติเดียวกันบน Node แทน:
```bash
openclaw approvals set --node --stdin <<'EOF'
{
version: 1,
defaults: {
security: "full",
ask: "off",
askFallback: "full"
}
}
EOF
```
**ข้อจำกัดเฉพาะภายในเครื่อง:**
- `openclaw exec-policy` ไม่ซิงโครไนซ์การอนุมัติของ Node
- `openclaw exec-policy set --host node` จะถูกปฏิเสธ
- การอนุมัติ exec ของ Node จะถูกดึงจาก Node ขณะรันไทม์ ดังนั้นการอัปเดตที่กำหนดเป้าหมายไปยัง Node ต้องใช้ `openclaw approvals --node ...`
### ทางลัดเฉพาะเซสชัน
- `/exec security=full ask=off` เปลี่ยนเฉพาะเซสชันปัจจุบัน
- `/elevated full` เป็นทางลัดฉุกเฉินที่ข้ามการอนุมัติ exec เฉพาะ
เมื่อนโยบายที่ร้องขอและไฟล์การอนุมัติของโฮสต์ต่างประเมินผลเป็น
`security: "full"` และ `ask: "off"` เท่านั้น ไฟล์โฮสต์ที่เข้มงวดกว่า เช่น `ask:
"always"` จะยังคงแสดงข้อความถาม
หากไฟล์การอนุมัติของโฮสต์ยังคงเข้มงวดกว่าการกำหนดค่า นโยบายของโฮสต์
ที่เข้มงวดกว่าจะยังคงมีผลเหนือกว่า
## รายการอนุญาต (ต่อเอเจนต์)
รายการอนุญาตเป็นแบบ **ต่อเอเจนต์** หากมีหลายเอเจนต์ ให้สลับเอเจนต์
ที่กำลังแก้ไขในแอป 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 ใช้ความหมายของนิพจน์ทั่วไป
ECMAScript (JavaScript) บนทุกโฮสต์ และประเมินนิพจน์กับ
อาร์กิวเมนต์คำสั่งที่แยกวิเคราะห์แล้ว โดยไม่รวมโทเค็นไฟล์ปฏิบัติการ (`argv[0]`)
สำหรับรายการที่เขียนด้วยตนเอง อาร์กิวเมนต์จะถูกเชื่อมด้วยช่องว่างหนึ่งช่อง ดังนั้น
ให้ยึดรูปแบบด้วยจุดเริ่มต้นและจุดสิ้นสุดเมื่อต้องการการจับคู่ที่ตรงกันทุกประการ
```json
{
"version": 1,
"agents": {
"main": {
"allowlist": [
{
"pattern": "python3",
"argPattern": "^safe\\.py$"
}
]
}
}
}
```
รายการดังกล่าวอนุญาต `python3 safe.py`; ส่วน `python3 other.py` ไม่ตรงกับรายการอนุญาต
หากมีรายการเฉพาะพาธสำหรับไบนารีเดียวกันอยู่ด้วย อาร์กิวเมนต์ที่ไม่ตรงกัน
ยังสามารถย้อนกลับไปใช้รายการเฉพาะพาธนั้นได้ ละเว้นรายการเฉพาะพาธ
เมื่อเป้าหมายคือจำกัดไบนารีให้ใช้ได้เฉพาะกับอาร์กิวเมนต์ที่ประกาศไว้
รายการที่บันทึกโดยขั้นตอนการอนุมัติใช้รูปแบบตัวคั่นภายในเพื่อจับคู่
argv อย่างแม่นยำ ควรใช้ UI หรือขั้นตอนการอนุมัติเพื่อสร้างรายการเหล่านั้นใหม่
แทนการแก้ไขค่าที่เข้ารหัสด้วยตนเอง หาก OpenClaw ไม่สามารถแยกวิเคราะห์ argv
สำหรับเซกเมนต์คำสั่งได้ รายการที่มี `argPattern` จะไม่ตรงกัน
รายการอนุญาตแต่ละรายการรองรับ:
| ฟิลด์ | ความหมาย |
| ------------------ | ---------------------------------------------------- |
| `pattern` | glob ของพาธไบนารีที่ผ่านการแก้ไขแล้วหรือ glob ของชื่อคำสั่งเปล่า |
| `argPattern` | regex ของ argv แบบ ECMAScript ซึ่งเป็นทางเลือก; หากละเว้นจะเป็นแบบเฉพาะพาธ |
| `id` | ID แบบทึบแสงที่คงที่; สร้างเป็น UUID เมื่อไม่มีค่า |
| `source` | แหล่งที่มาของรายการ เช่น `allow-always` |
| `commandText` | อินพุตข้อความธรรมดาแบบเดิม; ถูกละทิ้งระหว่างโหลด |
| `lastUsedAt` | การประทับเวลาที่ใช้ล่าสุด |
| `lastUsedCommand` | คำสั่งล่าสุดที่ตรงกัน |
| `lastResolvedPath` | พาธไบนารีที่แก้ไขล่าสุด |
## อนุญาต CLI ของ Skills โดยอัตโนมัติ
เมื่อเปิดใช้ **อนุญาต CLI ของ Skills โดยอัตโนมัติ** (`autoAllowSkills`) ไฟล์ปฏิบัติการ
ที่ Skills ที่รู้จักอ้างอิงจะถือว่าอยู่ในรายการอนุญาตบน Node (Node ของ macOS
หรือโฮสต์ Node แบบไม่มีส่วนติดต่อผู้ใช้) โดยใช้ `skills.bins` ผ่าน Gateway RPC เพื่อ
ดึงรายการไบนารีของ Skills ปิดใช้ตัวเลือกนี้หากต้องการใช้
รายการอนุญาตแบบกำหนดเองที่เข้มงวด
- นี่คือ **รายการอนุญาตเพื่อความสะดวกโดยปริยาย** ซึ่งแยกจากรายการอนุญาตพาธที่กำหนดเอง
- มีไว้สำหรับสภาพแวดล้อมของผู้ดำเนินการที่เชื่อถือได้ ซึ่ง Gateway และ Node อยู่ภายในขอบเขตความเชื่อถือเดียวกัน
- หากต้องการความเชื่อถือแบบชัดเจนที่เข้มงวด ให้คง `autoAllowSkills: false` ไว้และใช้เฉพาะรายการอนุญาตพาธที่กำหนดเอง
## ไบนารีที่ปลอดภัยและการส่งต่อคำขออนุมัติ
สำหรับไบนารีที่ปลอดภัย (เส้นทางด่วนแบบรับอินพุตผ่าน stdin เท่านั้น) รายละเอียดการผูกอินเทอร์พรีเตอร์ และ
วิธีส่งต่อข้อความขออนุมัติไปยัง Slack/Discord/Telegram (หรือเรียกใช้เป็น
ไคลเอ็นต์การอนุมัติแบบเนทีฟ) โปรดดู
[การอนุมัติ Exec - ขั้นสูง](/th/tools/exec-approvals-advanced)
## การแก้ไขผ่าน Control UI
ใช้การ์ด **Control UI -> Nodes -> Exec approvals** เพื่อแก้ไขค่าเริ่มต้น
การแทนที่รายเอเจนต์ และรายการอนุญาต เลือกขอบเขต (Defaults หรือเอเจนต์)
ปรับนโยบาย เพิ่ม/ลบรูปแบบรายการอนุญาต แล้วเลือก **Save** UI
จะแสดงข้อมูลเมตาการใช้งานล่าสุดของแต่ละรูปแบบ เพื่อช่วยให้รายการเป็นระเบียบ
ตัวเลือกเป้าหมายจะเลือก **Gateway** (การอนุมัติภายในเครื่อง) หรือ **Node**
Node ต้องประกาศ `system.execApprovals.get/set` (แอป macOS หรือ
โฮสต์ Node แบบไม่มีส่วนติดต่อผู้ใช้) หาก Node ยังไม่ประกาศการอนุมัติ exec ให้แก้ไข
ไฟล์การอนุมัติภายในเครื่องของ Node โดยตรง
โฮสต์ Node บางประเภท รวมถึงแอปคู่หูบน Windows ใช้รูปแบบนโยบายการอนุมัติ
ที่แตกต่างกัน Control UI จะแสดงนโยบายดั้งเดิมของโฮสต์เหล่านี้แบบอ่านอย่างเดียว ใช้
แอปคู่หูหรือ `openclaw approvals set --node ` พร้อมรูปแบบ
นโยบายดั้งเดิมเพื่อแก้ไข โปรดดู [CLI การอนุมัติ](/th/cli/approvals)
CLI: `openclaw approvals` รองรับการแก้ไข Gateway หรือ Node โปรดดู
[CLI การอนุมัติ](/th/cli/approvals)
## ขั้นตอนการอนุมัติ
เมื่อจำเป็นต้องแสดงข้อความถาม Gateway จะเผยแพร่
`exec.approval.requested` ไปยังไคลเอ็นต์ของผู้ดำเนินการ Control UI และแอป
macOS จะตัดสินผลผ่าน `exec.approval.resolve` จากนั้น Gateway จะส่งต่อ
คำขอที่ได้รับอนุมัติไปยังโฮสต์ Node
สำหรับ `host=node` คำขออนุมัติจะรวมเพย์โหลด `systemRunPlan`
แบบมาตรฐาน Gateway ใช้แผนดังกล่าวเป็นบริบทคำสั่ง/cwd/เซสชัน
ที่เชื่อถือได้เมื่อส่งต่อคำขอ `system.run` ที่ได้รับอนุมัติ:
- พาธ exec ของ Node จะเตรียมแผนมาตรฐานหนึ่งแผนไว้ล่วงหน้า
- ระเบียนการอนุมัติจะจัดเก็บแผนดังกล่าวและข้อมูลเมตาการผูกของแผน
- เมื่อได้รับอนุมัติแล้ว การเรียก `system.run` ครั้งสุดท้ายที่ส่งต่อจะใช้แผนที่จัดเก็บไว้ซ้ำ แทนที่จะเชื่อถือการแก้ไขภายหลังจากผู้เรียก
- หากผู้เรียกเปลี่ยน `command`, `rawCommand`, `cwd`, `agentId` หรือ `sessionKey` หลังจากสร้างคำขออนุมัติแล้ว Gateway จะปฏิเสธการเรียกใช้ที่ส่งต่อเนื่องจากการอนุมัติไม่ตรงกัน
## เหตุการณ์ระบบและการปฏิเสธ
วงจรชีวิตของ exec จะโพสต์ข้อความระบบ `Exec finished` ไปยังเซสชันของเอเจนต์
หลังจาก Node รายงานว่าเสร็จสมบูรณ์ OpenClaw ยังสามารถส่งการแจ้งเตือนว่า
กำลังดำเนินการอยู่ได้เมื่อผ่านไป `tools.exec.approvalRunningNoticeMs` หลังจากได้รับอนุมัติ
(ค่าเริ่มต้น `10000`, `0` จะปิดใช้
การแจ้งเตือนนี้) การอนุมัติ exec ที่ถูกปฏิเสธถือเป็นสถานะสิ้นสุดสำหรับคำสั่งบนโฮสต์:
คำสั่งจะไม่ทำงาน
- สำหรับการอนุมัติแบบอะซิงโครนัสของเอเจนต์หลักที่มีเซสชันต้นทาง OpenClaw
จะโพสต์การปฏิเสธกลับเข้าไปในเซสชันนั้นเป็นการติดตามผลภายใน เพื่อให้เอเจนต์
หยุดรอคำสั่งอะซิงโครนัสและหลีกเลี่ยงการซ่อมแซมผลลัพธ์ที่ขาดหาย
- หากไม่มีเซสชันหรือไม่สามารถดำเนินเซสชันต่อได้ OpenClaw ยังสามารถ
รายงานการปฏิเสธอย่างกระชับไปยังผู้ดำเนินการหรือเส้นทางแชตโดยตรง
- การปฏิเสธสำหรับเซสชันของเอเจนต์ย่อยและ Cron จะไม่ถูกโพสต์กลับเข้าไปใน
เซสชันนั้น
การอนุมัติ exec ของโฮสต์ Gateway จะส่งเหตุการณ์วงจรชีวิตเมื่อเสร็จสมบูรณ์แบบเดียวกัน
exec ที่มีเกตการอนุมัติจะใช้ ID การอนุมัติซ้ำเพื่อเชื่อมโยงคำขอที่รอดำเนินการ
กับข้อความเสร็จสมบูรณ์/ปฏิเสธ (`Exec finished (gateway
id=...)` / `Exec denied (gateway id=...)`)
## ผลกระทบ
- **`full`** มีสิทธิ์สูง ควรใช้รายการอนุญาตเมื่อเป็นไปได้
- **`ask`** ช่วยให้ยังมีส่วนร่วมในการตัดสินใจ พร้อมทั้งอนุมัติได้อย่างรวดเร็ว
- รายการอนุญาตรายเอเจนต์ป้องกันไม่ให้การอนุมัติของเอเจนต์หนึ่งรั่วไหลไปยังเอเจนต์อื่น
- การอนุมัติใช้กับคำขอ exec บนโฮสต์จาก **ผู้ส่งที่ได้รับอนุญาต** เท่านั้น ผู้ส่งที่ไม่ได้รับอนุญาตไม่สามารถเรียก `/exec` ได้
- `/exec security=full` เป็นความสะดวกระดับเซสชันสำหรับผู้ดำเนินการที่ได้รับอนุญาต และข้ามการอนุมัติโดยตั้งใจ หากต้องการบล็อก exec บนโฮสต์อย่างเด็ดขาด ให้ตั้งค่าความปลอดภัยของการอนุมัติเป็น `deny` หรือปฏิเสธเครื่องมือ `exec` ผ่านนโยบายเครื่องมือ
## ที่เกี่ยวข้อง
ไบนารีที่ปลอดภัย การผูกอินเทอร์พรีเตอร์ และการส่งต่อคำขออนุมัติไปยังแชต
เครื่องมือเรียกใช้คำสั่งเชลล์
ช่องทางฉุกเฉินที่ข้ามการอนุมัติด้วย
โหมดแซนด์บ็อกซ์และการเข้าถึงพื้นที่ทำงาน
โมเดลความปลอดภัยและการเพิ่มความแข็งแกร่ง
กรณีที่ควรใช้การควบคุมแต่ละแบบ
พฤติกรรมการอนุญาตอัตโนมัติที่รองรับด้วย Skills