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

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

## ไบนารีปลอดภัย (เฉพาะ stdin)

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

<Warning>
**อย่า** เพิ่มไบนารีอินเทอร์พรีเตอร์หรือรันไทม์ (เช่น `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` ในโหมดไบนารีปลอดภัย
ให้ระบุแพตเทิร์นด้วย `-e`/`--regexp`; รูปแบบแพตเทิร์นแบบตำแหน่งจะถูกปฏิเสธ
เพื่อไม่ให้สามารถซ่อนโอเปอแรนด์ไฟล์เป็นอาร์กิวเมนต์ตำแหน่งที่กำกวมได้

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

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

แฟล็กที่ถูกปฏิเสธตามโปรไฟล์ไบนารีปลอดภัย:

[//]: # "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 ถูกปฏิบัติเป็น **ข้อความตามตัวอักษร** ณ เวลาเรียกใช้
(ไม่มีการขยาย glob และไม่มีการขยาย `$VARS`) สำหรับเซกเมนต์เฉพาะ stdin ดังนั้นแพตเทิร์น
เช่น `*` หรือ `$HOME/...` จึงไม่สามารถใช้ซ่อนการอ่านไฟล์ได้

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

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

### การเชื่อมคำสั่งเชลล์ ตัวห่อ และมัลติเพล็กเซอร์

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

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

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

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

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

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

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

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

- `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 จะแทนที่คีย์ส่วนกลาง
- รายการอนุญาตอยู่ใน `~/.openclaw/exec-approvals.json` เฉพาะโฮสต์ ภายใต้ `agents.<id>.allowlist` (หรือผ่าน Control UI / `openclaw approvals allowlist ...`)
- `openclaw security audit` เตือนด้วย `tools.exec.safe_bins_interpreter_unprofiled` เมื่อไบนารีอินเทอร์พรีเตอร์/รันไทม์ปรากฏใน `safeBins` โดยไม่มีโปรไฟล์ชัดเจน
- `openclaw doctor --fix` สามารถสร้างโครงรายการ `safeBinProfiles.<bin>` แบบกำหนดเองที่หายไปเป็น `{}` (ตรวจทานและทำให้เข้มงวดขึ้นภายหลัง) ไบนารีอินเทอร์พรีเตอร์/รันไทม์จะไม่ถูกสร้างโครงให้อัตโนมัติ

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

## คำสั่งอินเทอร์พรีเตอร์/รันไทม์

การรันอินเทอร์พรีเตอร์/รันไทม์ที่มีการอนุมัติรองรับนั้นตั้งใจให้เข้มงวด:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

บางช่องทางยังทำหน้าที่เป็นไคลเอ็นต์การอนุมัติแบบเนทีฟได้ด้วย ไคลเอ็นต์แบบเนทีฟจะเพิ่ม DM ของผู้อนุมัติ การกระจายไปยังแชทต้นทาง
และ 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 approval สองรายการสำหรับการอนุมัติผ่านแชท](/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 จะรักษาชนิด id การอนุมัติไว้ ดังนั้น id แบบ `plugin:` จึงสามารถแก้ไปยังการอนุมัติ Plugin
  ได้โดยไม่ต้องมีเลเยอร์สำรองภายใน Slack ชั้นที่สอง
- การกำหนดเส้นทาง DM/ช่องทางแบบเนทีฟของ Matrix และทางลัดรีแอกชันจัดการได้ทั้งการอนุมัติ exec และ Plugin;
  การอนุญาต Plugin ยังคงมาจาก `channels.matrix.dm.allowFrom`
- พรอมป์แบบเนทีฟของ Matrix มีเนื้อหาเหตุการณ์กำหนดเอง `com.openclaw.approval` ในเหตุการณ์พรอมป์แรก
  เพื่อให้ไคลเอ็นต์ Matrix ที่รู้จัก OpenClaw สามารถอ่านสถานะการอนุมัติแบบมีโครงสร้างได้ ขณะที่ไคลเอ็นต์มาตรฐาน
  ยังคงเก็บตัวสำรอง `/approve` แบบข้อความธรรมดาไว้
- ผู้ร้องขอไม่จำเป็นต้องเป็นผู้อนุมัติ
- แชทต้นทางสามารถอนุมัติได้โดยตรงด้วย `/approve` เมื่อแชทนั้นรองรับคำสั่งและการตอบกลับอยู่แล้ว
- ปุ่มอนุมัติ Discord แบบเนทีฟกำหนดเส้นทางตามชนิด id การอนุมัติ: id แบบ `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) — พฤติกรรม auto-allow ที่รองรับด้วย Skills