---
read_when:
    - การกำหนดค่าไบนารีที่ปลอดภัยหรือโปรไฟล์ไบนารีที่ปลอดภัยแบบกำหนดเอง
    - การส่งต่อคำขออนุมัติไปยัง Slack/Discord/Telegram หรือช่องทางแชทอื่น ๆ
    - การนำไคลเอนต์การอนุมัติแบบเนทีฟสำหรับช่องทางไปใช้
summary: 'การอนุมัติการเรียกใช้งานขั้นสูง: ไบนารีที่ปลอดภัย, การผูกตัวแปลภาษา, การส่งต่อการอนุมัติ, การส่งมอบแบบเนทีฟ'
title: การอนุมัติการดำเนินคำสั่ง — ขั้นสูง
x-i18n:
    generated_at: "2026-04-30T10:19:38Z"
    model: gpt-5.5
    provider: openai
    source_hash: de8a72ca1d23e55dc198ae3c5ad55a57660c2111feebfb89f08d8fa9584e4337
    source_path: tools/exec-approvals-advanced.md
    workflow: 16
---

หัวข้อขั้นสูงเกี่ยวกับการอนุมัติ exec: fast-path ของ `safeBins`, การผูก interpreter/runtime
และการส่งต่อการอนุมัติไปยังช่องทางแชต (รวมถึงการส่งแบบเนทีฟ)
สำหรับนโยบายหลักและโฟลว์การอนุมัติ โปรดดู [การอนุมัติ Exec](/th/tools/exec-approvals)

## บินารีปลอดภัย (stdin เท่านั้น)

`tools.exec.safeBins` กำหนดรายการขนาดเล็กของไบนารีแบบ **stdin เท่านั้น** (เช่น
`cut`) ที่สามารถรันในโหมดรายการอนุญาตได้ **โดยไม่ต้องมี** รายการอนุญาต
อย่างชัดเจน บินารีปลอดภัยจะปฏิเสธอาร์กิวเมนต์ไฟล์แบบ positional และโทเค็นที่ดูเหมือนพาธ ดังนั้นจึง
ทำงานได้เฉพาะกับสตรีมขาเข้าเท่านั้น ให้ถือว่านี่เป็น fast-path แบบแคบสำหรับ
ตัวกรองสตรีม ไม่ใช่รายการความเชื่อถือทั่วไป

<Warning>
อย่าเพิ่มไบนารี interpreter หรือ runtime (เช่น `python3`, `node`,
`ruby`, `bash`, `sh`, `zsh`) ลงใน `safeBins` หากคำสั่งสามารถประเมินโค้ด
เรียกใช้คำสั่งย่อย หรืออ่านไฟล์ได้โดยการออกแบบ ให้ใช้รายการอนุญาตอย่างชัดเจน
และเปิดพรอมป์การอนุมัติไว้ บินารีปลอดภัยแบบกำหนดเองต้องกำหนด
โปรไฟล์อย่างชัดเจนใน `tools.exec.safeBinProfiles.<bin>`
</Warning>

บินารีปลอดภัยเริ่มต้น:

[//]: # "SAFE_BIN_DEFAULTS:START"

`cut`, `uniq`, `head`, `tail`, `tr`, `wc`

[//]: # "SAFE_BIN_DEFAULTS:END"

`grep` และ `sort` ไม่อยู่ในรายการเริ่มต้น หากคุณเลือกใช้งาน ให้คง
รายการอนุญาตอย่างชัดเจนสำหรับเวิร์กโฟลว์ที่ไม่ใช่ stdin ของเครื่องมือเหล่านี้ สำหรับ `grep` ในโหมด safe-bin
ให้ระบุแพตเทิร์นด้วย `-e`/`--regexp`; รูปแบบแพตเทิร์นแบบ positional จะถูกปฏิเสธ
เพื่อไม่ให้สามารถแอบส่งตัวถูกดำเนินการไฟล์เป็น positional ที่กำกวมได้

### การตรวจสอบ argv และแฟล็กที่ถูกปฏิเสธ

การตรวจสอบกำหนดแบบ deterministic จากรูปทรงของ argv เท่านั้น (ไม่มีการตรวจสอบการมีอยู่ของระบบไฟล์บนโฮสต์)
ซึ่งป้องกันพฤติกรรม oracle เรื่องการมีอยู่ของไฟล์จากความแตกต่างของ allow/deny
ตัวเลือกที่มุ่งเน้นไฟล์จะถูกปฏิเสธสำหรับบินารีปลอดภัยเริ่มต้น; ตัวเลือกแบบยาว
จะตรวจสอบแบบ fail-closed (แฟล็กที่ไม่รู้จักและตัวย่อที่กำกวมจะถูกปฏิเสธ)

แฟล็กที่ถูกปฏิเสธตามโปรไฟล์ safe-bin:

[//]: # "SAFE_BIN_DENIED_FLAGS:START"

- `grep`: `--dereference-recursive`, `--directories`, `--exclude-from`, `--file`, `--recursive`, `-R`, `-d`, `-f`, `-r`
- `jq`: `--argfile`, `--from-file`, `--library-path`, `--rawfile`, `--slurpfile`, `-L`, `-f`
- `sort`: `--compress-program`, `--files0-from`, `--output`, `--random-source`, `--temporary-directory`, `-T`, `-o`
- `wc`: `--files0-from`

[//]: # "SAFE_BIN_DENIED_FLAGS:END"

บินารีปลอดภัยยังบังคับให้โทเค็น argv ถูกปฏิบัติเป็น **ข้อความ literal** ณ เวลาดำเนินการ
(ไม่มี globbing และไม่มีการขยาย `$VARS`) สำหรับเซกเมนต์ stdin-only ดังนั้นแพตเทิร์น
เช่น `*` หรือ `$HOME/...` จึงไม่สามารถใช้แอบอ่านไฟล์ได้

### ไดเรกทอรีไบนารีที่เชื่อถือได้

บินารีปลอดภัยต้อง resolve จากไดเรกทอรีไบนารีที่เชื่อถือได้ (ค่าเริ่มต้นของระบบรวมกับ
`tools.exec.safeBinTrustedDirs` ที่เป็นตัวเลือก) รายการ `PATH` จะไม่ถูกเชื่อถือโดยอัตโนมัติ
ไดเรกทอรีที่เชื่อถือได้เริ่มต้นตั้งใจให้มีน้อยที่สุด: `/bin`, `/usr/bin` หาก
ไฟล์ปฏิบัติการ safe-bin ของคุณอยู่ในพาธของ package-manager/ผู้ใช้ (เช่น
`/opt/homebrew/bin`, `/usr/local/bin`, `/opt/local/bin`, `/snap/bin`) ให้เพิ่มพาธเหล่านั้น
อย่างชัดเจนใน `tools.exec.safeBinTrustedDirs`

### การ chain เชลล์, wrapper และ multiplexer

การ chain เชลล์ (`&&`, `||`, `;`) อนุญาตเมื่อทุกเซกเมนต์ระดับบน
ผ่านรายการอนุญาต (รวมถึงบินารีปลอดภัยหรือการอนุญาตอัตโนมัติของ Skills) การเปลี่ยนทิศทาง
ยังไม่รองรับในโหมดรายการอนุญาต การแทนที่คำสั่ง (`$()` / backticks) จะถูก
ปฏิเสธระหว่างการ parse รายการอนุญาต รวมถึงภายในเครื่องหมายคำพูดคู่; ใช้เครื่องหมายคำพูดเดี่ยว
หากคุณต้องการข้อความ literal `$()`

สำหรับการอนุมัติในแอปคู่บน macOS ข้อความเชลล์ดิบที่มีไวยากรณ์ควบคุมเชลล์หรือ
การขยาย (`&&`, `||`, `;`, `|`, `` ` ``, `$`, `<`, `>`, `(`, `)`) จะ
ถือว่าไม่ตรงกับรายการอนุญาต เว้นแต่ไบนารีเชลล์นั้นเองจะอยู่ในรายการอนุญาต

สำหรับ shell wrapper (`bash|sh|zsh ... -c/-lc`) env override ระดับคำขอจะ
ถูกลดเหลือรายการอนุญาตขนาดเล็กที่ชัดเจน (`TERM`, `LANG`, `LC_*`, `COLORTERM`,
`NO_COLOR`, `FORCE_COLOR`)

สำหรับการตัดสินใจ `allow-always` ในโหมดรายการอนุญาต wrapper สำหรับ dispatch ที่รู้จัก (`env`,
`nice`, `nohup`, `stdbuf`, `timeout`) จะบันทึกพาธไฟล์ปฏิบัติการภายในแทน
พาธของ wrapper shell multiplexer (`busybox`, `toybox`) จะถูกแกะสำหรับ
shell applet (`sh`, `ash` เป็นต้น) ในลักษณะเดียวกัน หาก wrapper หรือ multiplexer
ไม่สามารถแกะได้อย่างปลอดภัย จะไม่มีการบันทึกรายการอนุญาตโดยอัตโนมัติ

หากคุณใส่ interpreter เช่น `python3` หรือ `node` ลงในรายการอนุญาต ให้ใช้
`tools.exec.strictInlineEval=true` เพื่อให้ inline eval ยังคงต้องมี
การอนุมัติอย่างชัดเจน ในโหมด strict, `allow-always` ยังสามารถบันทึก
การเรียก interpreter/script ที่ไม่มีอันตรายได้ แต่ carrier ของ inline-eval จะไม่ถูกบันทึก
โดยอัตโนมัติ

### บินารีปลอดภัยเทียบกับรายการอนุญาต

| หัวข้อ            | `tools.exec.safeBins`                                  | รายการอนุญาต (`exec-approvals.json`)                                                  |
| ---------------- | ------------------------------------------------------ | ---------------------------------------------------------------------------------- |
| เป้าหมาย             | อนุญาตตัวกรอง stdin แบบแคบโดยอัตโนมัติ                        | เชื่อถือไฟล์ปฏิบัติการเฉพาะอย่างชัดเจน                                              |
| ชนิดการจับคู่       | ชื่อไฟล์ปฏิบัติการ + นโยบาย argv ของ safe-bin                 | glob ของพาธไฟล์ปฏิบัติการที่ resolve แล้ว หรือ glob ชื่อคำสั่งเปล่าสำหรับคำสั่งที่เรียกผ่าน PATH |
| ขอบเขตอาร์กิวเมนต์   | จำกัดโดยโปรไฟล์ safe-bin และกฎโทเค็น literal | จับคู่เฉพาะพาธ; อาร์กิวเมนต์อื่นเป็นความรับผิดชอบของคุณ                       |
| ตัวอย่างทั่วไป | `head`, `tail`, `tr`, `wc`                             | `jq`, `python3`, `node`, `ffmpeg`, CLI แบบกำหนดเอง                                     |
| การใช้งานที่เหมาะที่สุด         | การแปลงข้อความความเสี่ยงต่ำใน pipeline                  | เครื่องมือใด ๆ ที่มีพฤติกรรมกว้างขึ้นหรือมีผลข้างเคียง                                     |

ตำแหน่งการกำหนดค่า:

- `safeBins` มาจาก config (`tools.exec.safeBins` หรือ `agents.list[].tools.exec.safeBins` ต่อ agent)
- `safeBinTrustedDirs` มาจาก config (`tools.exec.safeBinTrustedDirs` หรือ `agents.list[].tools.exec.safeBinTrustedDirs` ต่อ agent)
- `safeBinProfiles` มาจาก config (`tools.exec.safeBinProfiles` หรือ `agents.list[].tools.exec.safeBinProfiles` ต่อ agent) คีย์โปรไฟล์ต่อ agent จะแทนที่คีย์ global
- รายการอนุญาตอยู่ใน `~/.openclaw/exec-approvals.json` ที่เป็น host-local ภายใต้ `agents.<id>.allowlist` (หรือผ่าน Control UI / `openclaw approvals allowlist ...`)
- `openclaw security audit` เตือนด้วย `tools.exec.safe_bins_interpreter_unprofiled` เมื่อบินารี interpreter/runtime ปรากฏใน `safeBins` โดยไม่มีโปรไฟล์อย่างชัดเจน
- `openclaw doctor --fix` สามารถ scaffold รายการ `safeBinProfiles.<bin>` แบบกำหนดเองที่หายไปเป็น `{}` (ตรวจทานและทำให้เข้มงวดขึ้นภายหลัง) บินารี interpreter/runtime จะไม่ถูก scaffold โดยอัตโนมัติ

ตัวอย่างโปรไฟล์แบบกำหนดเอง:
__OC_I18N_900000__
หากคุณเลือกเพิ่ม `jq` ลงใน `safeBins` อย่างชัดเจน OpenClaw ยังปฏิเสธ builtin `env` ในโหมด safe-bin
เพื่อให้ `jq -n env` ไม่สามารถ dump environment ของ process โฮสต์ได้โดยไม่มีพาธรายการอนุญาต
หรือพรอมป์การอนุมัติอย่างชัดเจน

## คำสั่ง interpreter/runtime

การรัน interpreter/runtime ที่รองรับด้วยการอนุมัติจะระมัดระวังโดยตั้งใจ:

- มีการผูกบริบท argv/cwd/env ที่แน่นอนเสมอ
- รูปแบบ shell script โดยตรงและไฟล์ runtime โดยตรงจะพยายามผูกกับสแนปช็อตไฟล์ local ที่เป็นรูปธรรมหนึ่งไฟล์อย่างดีที่สุด
- รูปแบบ wrapper ของ package-manager ทั่วไปที่ยัง resolve เป็นไฟล์ local โดยตรงหนึ่งไฟล์ (เช่น
  `pnpm exec`, `pnpm node`, `npm exec`, `npx`) จะถูกแกะก่อนการผูก
- หาก OpenClaw ไม่สามารถระบุไฟล์ local ที่เป็นรูปธรรมได้แน่ชัดหนึ่งไฟล์สำหรับคำสั่ง interpreter/runtime
  (เช่น package script, รูปแบบ eval, เชน loader เฉพาะ runtime หรือรูปแบบหลายไฟล์ที่กำกวม)
  การดำเนินการที่รองรับด้วยการอนุมัติจะถูกปฏิเสธ แทนที่จะอ้างว่าครอบคลุมเชิงความหมายในสิ่งที่ไม่ครอบคลุม
- สำหรับเวิร์กโฟลว์เหล่านั้น ให้ใช้ sandboxing, ขอบเขตโฮสต์แยกต่างหาก หรือรายการอนุญาต/เวิร์กโฟลว์เต็มที่เชื่อถืออย่างชัดเจน
  ซึ่งผู้ปฏิบัติการยอมรับ semantics ของ runtime ที่กว้างกว่า

เมื่อจำเป็นต้องมีการอนุมัติ เครื่องมือ exec จะส่งคืนทันทีพร้อม id การอนุมัติ ใช้ id นั้นเพื่อ
เชื่อมโยงกับเหตุการณ์ระบบภายหลัง (`Exec finished` / `Exec denied`) หากไม่มีการตัดสินใจก่อน
timeout คำขอจะถูกถือว่าเป็น timeout การอนุมัติและแสดงเป็นเหตุผลการปฏิเสธ

### พฤติกรรมการส่ง followup

หลังจาก async exec ที่ได้รับอนุมัติเสร็จสิ้น OpenClaw จะส่งเทิร์น `agent` followup ไปยัง session เดิม

- หากมีเป้าหมายการส่งภายนอกที่ถูกต้อง (ช่องทางที่ส่งได้พร้อมเป้าหมาย `to`) การส่ง followup จะใช้ช่องทางนั้น
- ในโฟลว์ webchat-only หรือ session ภายในที่ไม่มีเป้าหมายภายนอก การส่ง followup จะอยู่เฉพาะใน session (`deliver: false`)
- หากผู้เรียกขอการส่งภายนอกแบบ strict อย่างชัดเจนโดยไม่มีช่องทางภายนอกที่ resolve ได้ คำขอจะล้มเหลวด้วย `INVALID_REQUEST`
- หากเปิดใช้ `bestEffortDeliver` และไม่สามารถ resolve ช่องทางภายนอกได้ การส่งจะถูกลดระดับเป็น session-only แทนที่จะล้มเหลว

## การส่งต่อการอนุมัติไปยังช่องทางแชต

คุณสามารถส่งต่อพรอมป์การอนุมัติ exec ไปยังช่องทางแชตใดก็ได้ (รวมถึงช่องทาง Plugin) และอนุมัติ
ด้วย `/approve` ซึ่งใช้ pipeline การส่งออกตามปกติ

Config:
__OC_I18N_900001__
ตอบกลับในแชต:
__OC_I18N_900002__
คำสั่ง `/approve` จัดการทั้งการอนุมัติ exec และการอนุมัติ Plugin หาก ID ไม่ตรงกับการอนุมัติ exec ที่ pending อยู่ ระบบจะตรวจสอบการอนุมัติ Plugin แทนโดยอัตโนมัติ

### การส่งต่อการอนุมัติ Plugin

การส่งต่อการอนุมัติ Plugin ใช้ pipeline การส่งเดียวกับการอนุมัติ exec แต่มี
config อิสระของตัวเองภายใต้ `approvals.plugin` การเปิดหรือปิดอย่างหนึ่งไม่ส่งผลต่ออีกอย่างหนึ่ง
__OC_I18N_900003__
รูปทรง config เหมือนกับ `approvals.exec`: `enabled`, `mode`, `agentFilter`,
`sessionFilter` และ `targets` ทำงานเหมือนกัน

ช่องทางที่รองรับการตอบกลับแบบโต้ตอบร่วมจะแสดงปุ่มอนุมัติเดียวกันสำหรับทั้งการอนุมัติ exec และ
การอนุมัติ Plugin ช่องทางที่ไม่มี UI แบบโต้ตอบร่วมจะ fallback เป็นข้อความธรรมดาพร้อมคำแนะนำ
`/approve`

### การอนุมัติในแชตเดียวกันบนทุกช่องทาง

เมื่อคำขออนุมัติ exec หรือ Plugin มาจากพื้นผิวแชตที่ส่งได้ แชตเดียวกัน
สามารถอนุมัติด้วย `/approve` ได้ตามค่าเริ่มต้นแล้ว สิ่งนี้ใช้กับช่องทางเช่น Slack, Matrix และ
Microsoft Teams นอกเหนือจากโฟลว์ Web UI และ terminal UI ที่มีอยู่

เส้นทางคำสั่งข้อความร่วมนี้ใช้โมเดล auth ของช่องทางตามปกติสำหรับบทสนทนานั้น หาก
แชตต้นทางสามารถส่งคำสั่งและรับการตอบกลับได้อยู่แล้ว คำขออนุมัติไม่จำเป็นต้องมี
adapter การส่งแบบเนทีฟแยกต่างหากเพียงเพื่อให้ยัง pending อยู่

Discord และ Telegram ยังรองรับ `/approve` ในแชตเดียวกันด้วย แต่ช่องทางเหล่านั้นยังใช้
รายการผู้อนุมัติที่ resolve แล้วสำหรับการอนุญาต แม้เมื่อปิดใช้งานการส่งการอนุมัติแบบเนทีฟ

สำหรับ Telegram และไคลเอนต์การอนุมัติแบบเนทีฟอื่นที่เรียก Gateway โดยตรง
fallback นี้ตั้งใจจำกัดไว้เฉพาะความล้มเหลวแบบ "ไม่พบการอนุมัติ" เท่านั้น การปฏิเสธ/ข้อผิดพลาด
การอนุมัติ exec จริงจะไม่ retry แบบเงียบเป็นการอนุมัติ Plugin

### การส่งการอนุมัติแบบเนทีฟ

บางช่องทางยังสามารถทำหน้าที่เป็นไคลเอนต์การอนุมัติแบบเนทีฟได้ ไคลเอนต์เนทีฟเพิ่ม DM ถึงผู้อนุมัติ, fanout ไปยังแชตต้นทาง
และ UX การอนุมัติแบบโต้ตอบเฉพาะช่องทางไว้บนโฟลว์ `/approve`
ในแชตเดียวกันร่วมกัน

เมื่อมีการ์ด/ปุ่มอนุมัติแบบเนทีฟ UI แบบเนทีฟนั้นคือเส้นทางหลักที่แสดงต่อเอเจนต์ เอเจนต์ไม่ควรสะท้อนคำสั่งแชตธรรมดา `/approve` ซ้ำอีก เว้นแต่ผลลัพธ์ของเครื่องมือจะระบุว่าไม่สามารถใช้การอนุมัติผ่านแชตได้ หรือการอนุมัติด้วยตนเองเป็นเส้นทางเดียวที่เหลืออยู่

หากกำหนดค่าไคลเอนต์การอนุมัติแบบเนทีฟไว้ แต่ไม่มีรันไทม์แบบเนทีฟที่ทำงานอยู่สำหรับช่องทางต้นทาง OpenClaw จะคงพรอมป์ `/approve` แบบกำหนดแน่นอนในเครื่องให้มองเห็นอยู่ หากรันไทม์แบบเนทีฟทำงานอยู่และพยายามส่ง แต่ไม่มีเป้าหมายใดได้รับการ์ด OpenClaw จะส่งประกาศสำรองในแชตเดียวกันพร้อมคำสั่ง `/approve <id> <decision>` ที่ตรงเป๊ะ เพื่อให้ยังสามารถจัดการคำขอได้

โมเดลทั่วไป:

- นโยบาย exec ของโฮสต์ยังคงตัดสินว่าจำเป็นต้องมีการอนุมัติ exec หรือไม่
- `approvals.exec` ควบคุมการส่งต่อพรอมป์การอนุมัติไปยังปลายทางแชตอื่น
- `channels.<channel>.execApprovals` ควบคุมว่าช่องทางนั้นทำหน้าที่เป็นไคลเอนต์การอนุมัติแบบเนทีฟหรือไม่

ไคลเอนต์การอนุมัติแบบเนทีฟจะเปิดใช้งานการส่งแบบ DM ก่อนโดยอัตโนมัติเมื่อเงื่อนไขทั้งหมดต่อไปนี้เป็นจริง:

- ช่องทางรองรับการส่งการอนุมัติแบบเนทีฟ
- สามารถระบุผู้อนุมัติได้จาก `execApprovals.approvers` ที่ระบุชัดเจน หรือจากตัวตนเจ้าของ
  เช่น `commands.ownerAllowFrom`
- `channels.<channel>.execApprovals.enabled` ไม่ได้ตั้งค่าไว้ หรือเป็น `"auto"`

ตั้งค่า `enabled: false` เพื่อปิดใช้ไคลเอนต์การอนุมัติแบบเนทีฟอย่างชัดเจน ตั้งค่า `enabled: true` เพื่อบังคับเปิดใช้งานเมื่อระบุผู้อนุมัติได้ การส่งไปยังแชตต้นทางแบบสาธารณะยังคงต้องระบุชัดเจนผ่าน `channels.<channel>.execApprovals.target`

FAQ: [ทำไมจึงมีการกำหนดค่าการอนุมัติ exec สองรายการสำหรับการอนุมัติผ่านแชต](/help/faq-first-run#why-are-there-two-exec-approval-configs-for-chat-approvals)

- Discord: `channels.discord.execApprovals.*`
- Slack: `channels.slack.execApprovals.*`
- Telegram: `channels.telegram.execApprovals.*`

ไคลเอนต์การอนุมัติแบบเนทีฟเหล่านี้เพิ่มการกำหนดเส้นทาง DM และการกระจายไปยังช่องทางแบบเลือกได้ไว้เหนือโฟลว์ `/approve` ในแชตเดียวกันที่ใช้ร่วมกัน และปุ่มอนุมัติที่ใช้ร่วมกัน

พฤติกรรมที่ใช้ร่วมกัน:

- Slack, Matrix, Microsoft Teams และแชตที่ส่งถึงได้ในลักษณะคล้ายกัน ใช้โมเดลการยืนยันตัวตนของช่องทางตามปกติ
  สำหรับ `/approve` ในแชตเดียวกัน
- เมื่อไคลเอนต์การอนุมัติแบบเนทีฟเปิดใช้งานอัตโนมัติ เป้าหมายการส่งแบบเนทีฟเริ่มต้นคือ DM ของผู้อนุมัติ
- สำหรับ Discord และ Telegram เฉพาะผู้อนุมัติที่ระบุได้เท่านั้นที่สามารถอนุมัติหรือปฏิเสธได้
- ผู้อนุมัติของ Discord สามารถระบุชัดเจน (`execApprovals.approvers`) หรืออนุมานจาก `commands.ownerAllowFrom`
- ผู้อนุมัติของ Telegram สามารถระบุชัดเจน (`execApprovals.approvers`) หรืออนุมานจาก `commands.ownerAllowFrom`
- ผู้อนุมัติของ Slack สามารถระบุชัดเจน (`execApprovals.approvers`) หรืออนุมานจาก `commands.ownerAllowFrom`
- ปุ่มแบบเนทีฟของ Slack จะรักษาชนิดของรหัสการอนุมัติไว้ ดังนั้นรหัส `plugin:` จึงสามารถเชื่อมไปยังการอนุมัติ Plugin ได้
  โดยไม่ต้องมีชั้นสำรองเฉพาะ Slack เพิ่มอีกชั้น
- การกำหนดเส้นทาง DM/ช่องทางแบบเนทีฟของ Matrix และทางลัดด้วยรีแอ็กชันรองรับทั้งการอนุมัติ exec และ Plugin;
  การอนุญาต Plugin ยังคงมาจาก `channels.matrix.dm.allowFrom`
- พรอมป์แบบเนทีฟของ Matrix มีเนื้อหาเหตุการณ์กำหนดเอง `com.openclaw.approval` ในเหตุการณ์พรอมป์แรก
  เพื่อให้ไคลเอนต์ Matrix ที่รู้จัก OpenClaw อ่านสถานะการอนุมัติแบบมีโครงสร้างได้ ขณะที่ไคลเอนต์มาตรฐาน
  ยังคงใช้ข้อความสำรอง `/approve` แบบข้อความล้วน
- ผู้ร้องขอไม่จำเป็นต้องเป็นผู้อนุมัติ
- แชตต้นทางสามารถอนุมัติได้โดยตรงด้วย `/approve` เมื่อแชตนั้นรองรับคำสั่งและการตอบกลับอยู่แล้ว
- ปุ่มอนุมัติแบบเนทีฟของ Discord กำหนดเส้นทางตามชนิดของรหัสการอนุมัติ: รหัส `plugin:` จะไป
  ยังการอนุมัติ Plugin โดยตรง ส่วนที่เหลือทั้งหมดจะไปยังการอนุมัติ exec
- ปุ่มอนุมัติแบบเนทีฟของ Telegram ใช้การสำรองจาก exec ไปยัง Plugin แบบมีขอบเขตเดียวกับ `/approve`
- เมื่อ `target` แบบเนทีฟเปิดใช้งานการส่งไปยังแชตต้นทาง พรอมป์การอนุมัติจะมีข้อความคำสั่งรวมอยู่ด้วย
- การอนุมัติ exec ที่รอดำเนินการจะหมดอายุหลังจาก 30 นาทีตามค่าเริ่มต้น
- หากไม่มี UI สำหรับผู้ปฏิบัติการหรือไคลเอนต์การอนุมัติที่กำหนดค่าไว้ซึ่งสามารถรับคำขอได้ พรอมป์จะถอยกลับไปใช้ `askFallback`

คำสั่งกลุ่มที่ละเอียดอ่อนและจำกัดเฉพาะเจ้าของ เช่น `/diagnostics` และ `/export-trajectory` ใช้การกำหนดเส้นทางเจ้าของแบบส่วนตัวสำหรับพรอมป์การอนุมัติและผลลัพธ์สุดท้าย OpenClaw จะลองใช้เส้นทางส่วนตัวบนพื้นผิวเดียวกับที่เจ้าของเรียกใช้คำสั่งก่อน หากพื้นผิวนั้นไม่มีเส้นทางเจ้าของแบบส่วนตัว ระบบจะถอยกลับไปยังเส้นทางเจ้าของแรกที่มีจาก `commands.ownerAllowFrom` ดังนั้นคำสั่งกลุ่มใน Discord ยังสามารถส่งการอนุมัติและผลลัพธ์ไปยัง DM ของเจ้าของใน Telegram ได้ เมื่อ Telegram เป็นอินเทอร์เฟซส่วนตัวหลักที่กำหนดค่าไว้ แชตกลุ่มจะได้รับเพียงการตอบรับสั้น ๆ

Telegram ใช้ค่าเริ่มต้นเป็น DM ของผู้อนุมัติ (`target: "dm"`) คุณสามารถเปลี่ยนเป็น `channel` หรือ `both` เมื่อคุณต้องการให้พรอมป์การอนุมัติปรากฏในแชต/หัวข้อ Telegram ต้นทางด้วย สำหรับหัวข้อฟอรัมของ Telegram OpenClaw จะคงหัวข้อไว้สำหรับพรอมป์การอนุมัติและการติดตามผลหลังอนุมัติ

ดู:

- [Discord](/channels/discord)
- [Telegram](/channels/telegram)

### โฟลว์ IPC บน macOS
__OC_I18N_900004__
หมายเหตุด้านความปลอดภัย:

- โหมด Unix socket `0600`, token จัดเก็บไว้ใน `exec-approvals.json`
- การตรวจสอบเพียร์ที่เป็น UID เดียวกัน
- Challenge/response (nonce + HMAC token + request hash) + TTL สั้น

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

- [การอนุมัติ exec](/th/tools/exec-approvals) — นโยบายหลักและโฟลว์การอนุมัติ
- [เครื่องมือ exec](/th/tools/exec)
- [โหมด Elevated](/th/tools/elevated)
- [Skills](/th/tools/skills) — พฤติกรรมอนุญาตอัตโนมัติที่รองรับด้วย skill
