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

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

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

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

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

cut, uniq, head, tail, tr, wc

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

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

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

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

• 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

ไบนารีปลอดภัยยังบังคับให้โทเค็น 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 สองรายการสำหรับการอนุมัติผ่านแชท

• 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
• Telegram

# โฟลว์ IPC ของ macOS

OC_I18N_900004 หมายเหตุด้านความปลอดภัย:

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

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

• การอนุมัติ exec — นโยบายหลักและโฟลว์การอนุมัติ
• เครื่องมือ exec
• โหมด elevated
• Skills — พฤติกรรม auto-allow ที่รองรับด้วย Skills