---
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)

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

## ขอบเขตการใช้งาน

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

<Note>
การแทนที่ `/exec` แยกตามเซสชันจะไม่รวมอยู่ด้วย เรียกใช้ `/exec` ในเซสชันที่เกี่ยวข้องเพื่อตรวจสอบค่าเริ่มต้นปัจจุบัน โปรดดู [การแทนที่ของเซสชัน](/th/tools/exec#session-overrides-exec)
</Note>

ข้อมูลอ้างอิง CLI ฉบับเต็ม (แฟล็ก, เอาต์พุต JSON, การเพิ่ม/ลบรายการอนุญาต): [CLI การอนุมัติ](/th/cli/approvals)

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

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

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

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

การอนุมัติจะอยู่ในไฟล์ 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`

<ParamField path="security" type='"deny" | "allowlist" | "full"'>
  - `deny` - บล็อกคำขอ exec บนโฮสต์ทั้งหมด
  - `allowlist` - อนุญาตเฉพาะคำสั่งในรายการอนุญาต
  - `full` - อนุญาตทุกอย่าง (เทียบเท่ากับ elevated)

ค่าเริ่มต้นคือ `full` สำหรับโฮสต์ Gateway/Node ส่วนโฮสต์ `sandbox` จะมีค่าเริ่มต้นเป็น
`deny` แทน
</ParamField>

### `exec.ask`

<ParamField path="ask" type='"off" | "on-miss" | "always"'>
  นโยบาย ask ที่กำหนดค่าไว้สำหรับ exec บนโฮสต์ ควบคุมลักษณะพื้นฐานของ
  ข้อความขออนุมัติจาก `tools.exec.ask` และค่าเริ่มต้นของการอนุมัติโฮสต์
  ค่าเริ่มต้นคือ `off` พารามิเตอร์เครื่องมือ `ask` แยกตามการเรียก (ดู
  [เครื่องมือ Exec](/th/tools/exec#parameters)) ทำได้เพียงเพิ่มความเข้มงวดให้กับค่าพื้นฐานนั้น และ
  การเรียกโมเดลที่มาจากช่องทางจะไม่สนใจพารามิเตอร์นี้เมื่อ ask ของโฮสต์ที่มีผลเป็น `off`

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

</ParamField>

### `askFallback`

<ParamField path="askFallback" type='"deny" | "allowlist" | "full"'>
  การตัดสินเมื่อจำเป็นต้องแสดงข้อความถามแต่ไม่สามารถเข้าถึง UI ได้ (หรือ
  ข้อความถามหมดเวลา) ค่าเริ่มต้นคือ `deny` เมื่อละเว้น

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

</ParamField>

### `tools.exec.strictInlineEval`

<ParamField path="strictInlineEval" type="boolean">
  เมื่อ `true` ให้ถือว่ารูปแบบการประเมินโค้ดแบบอินไลน์ต้องได้รับการอนุมัติเท่านั้น แม้ว่า
  ไบนารีอินเทอร์พรีเตอร์จะอยู่ในรายการอนุญาต เป็นการป้องกันเชิงลึกสำหรับ
  ตัวโหลดอินเทอร์พรีเตอร์ที่ไม่สามารถแมปกับโอเปอแรนด์ไฟล์ที่เสถียรหนึ่งรายการได้อย่างชัดเจน
</ParamField>

ตัวอย่างที่โหมดเข้มงวดตรวจจับได้: `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`

<ParamField path="commandHighlighting" type="boolean" default="false">
  ใช้เพื่อการนำเสนอเท่านั้น: เมื่อเปิดใช้งาน OpenClaw อาจแนบ
  ช่วงคำสั่งที่ได้จากตัวแยกวิเคราะห์ เพื่อให้ข้อความขออนุมัติบนเว็บสามารถเน้นโทเค็นคำสั่งได้ การตั้งค่านี้
  **ไม่** เปลี่ยน `security`, `ask`, การจับคู่รายการอนุญาต, ลักษณะการทำงานของ
  การประเมินแบบอินไลน์ที่เข้มงวด, การส่งต่อการอนุมัติ หรือการเรียกใช้คำสั่ง
</ParamField>

กำหนดแบบส่วนกลางภายใต้ `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`                     |

<Warning>
**ข้อแตกต่างที่สำคัญ:**

- `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=...` อย่างชัดเจน

</Warning>

ผู้ให้บริการที่ใช้ 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

<Steps>
  <Step title="ตั้งค่านโยบายการกำหนดค่าที่ต้องการ">
    ```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
    ```
  </Step>
  <Step title="ปรับไฟล์การอนุมัติของโฮสต์ให้ตรงกัน">
    ```bash
    openclaw approvals set --stdin <<'EOF'
    {
      version: 1,
      defaults: {
        security: "full",
        ask: "off",
        askFallback: "full"
      }
    }
    EOF
    ```
  </Step>
</Steps>

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

```bash
openclaw exec-policy preset yolo
```

อัปเดตทั้ง `tools.exec.host/security/ask` ภายในเครื่องและค่าเริ่มต้นของไฟล์การอนุมัติ
ภายในเครื่อง (รวมถึง `askFallback: "full"`) โดยตั้งใจให้มีผล
เฉพาะภายในเครื่อง หากต้องการเปลี่ยนการอนุมัติของโฮสต์ Gateway หรือโฮสต์ Node จากระยะไกล ให้ใช้
`openclaw approvals set --gateway` หรือ `openclaw approvals set --node
<id|name|ip>`

พรีเซ็ตในตัวอื่น ๆ ได้แก่ `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 <auto|sandbox|gateway|node> --security
<deny|allowlist|full> --ask <off|on-miss|always> --ask-fallback
<deny|allowlist|full>` พร้อมชุดย่อยใด ๆ ของแฟล็กเหล่านั้น

### โฮสต์ Node

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

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

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

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

</Note>

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

- `/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 ปิดใช้ตัวเลือกนี้หากต้องการใช้
รายการอนุญาตแบบกำหนดเองที่เข้มงวด

<Warning>
- นี่คือ **รายการอนุญาตเพื่อความสะดวกโดยปริยาย** ซึ่งแยกจากรายการอนุญาตพาธที่กำหนดเอง
- มีไว้สำหรับสภาพแวดล้อมของผู้ดำเนินการที่เชื่อถือได้ ซึ่ง Gateway และ Node อยู่ภายในขอบเขตความเชื่อถือเดียวกัน
- หากต้องการความเชื่อถือแบบชัดเจนที่เข้มงวด ให้คง `autoAllowSkills: false` ไว้และใช้เฉพาะรายการอนุญาตพาธที่กำหนดเอง

</Warning>

## ไบนารีที่ปลอดภัยและการส่งต่อคำขออนุมัติ

สำหรับไบนารีที่ปลอดภัย (เส้นทางด่วนแบบรับอินพุตผ่าน 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 <id|name|ip>` พร้อมรูปแบบ
นโยบายดั้งเดิมเพื่อแก้ไข โปรดดู [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` ผ่านนโยบายเครื่องมือ

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

<CardGroup cols={2}>
  <Card title="การอนุมัติ Exec - ขั้นสูง" href="/th/tools/exec-approvals-advanced" icon="gear">
    ไบนารีที่ปลอดภัย การผูกอินเทอร์พรีเตอร์ และการส่งต่อคำขออนุมัติไปยังแชต
  </Card>
  <Card title="เครื่องมือ Exec" href="/th/tools/exec" icon="terminal">
    เครื่องมือเรียกใช้คำสั่งเชลล์
  </Card>
  <Card title="โหมดยกระดับสิทธิ์" href="/th/tools/elevated" icon="shield-exclamation">
    ช่องทางฉุกเฉินที่ข้ามการอนุมัติด้วย
  </Card>
  <Card title="การทำแซนด์บ็อกซ์" href="/th/gateway/sandboxing" icon="box">
    โหมดแซนด์บ็อกซ์และการเข้าถึงพื้นที่ทำงาน
  </Card>
  <Card title="ความปลอดภัย" href="/th/gateway/security" icon="lock">
    โมเดลความปลอดภัยและการเพิ่มความแข็งแกร่ง
  </Card>
  <Card title="แซนด์บ็อกซ์เทียบกับนโยบายเครื่องมือเทียบกับการยกระดับสิทธิ์" href="/th/gateway/sandbox-vs-tool-policy-vs-elevated" icon="sliders">
    กรณีที่ควรใช้การควบคุมแต่ละแบบ
  </Card>
  <Card title="Skills" href="/th/tools/skills" icon="sparkles">
    พฤติกรรมการอนุญาตอัตโนมัติที่รองรับด้วย Skills
  </Card>
</CardGroup>
