---
read_when:
    - การออกแบบพฤติกรรมการค้นหา การดำเนินต่อ หรือการเก็บถาวรเซสชัน Codex
    - การเปลี่ยน UI แค็ตตาล็อกเซสชันแบบเนทีฟหรือ RPC ของ Gateway
    - การขยายการกำกับดูแล Codex ครอบคลุม Node ที่จับคู่กัน
summary: สถาปัตยกรรมและขอบเขตผลิตภัณฑ์สำหรับการควบคุมดูแลเซสชัน Codex แบบเนทีฟจาก OpenClaw
title: การควบคุมดูแล Codex
x-i18n:
    generated_at: "2026-07-19T07:32:00Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 5e259badc8f7fdec6fa093785a1dd04394e12287ae61f00474bcd45e7b95352d
    source_path: specs/codex-supervision.md
    workflow: 16
---

# การกำกับดูแล Codex

## เป้าหมาย

การกำกับดูแล Codex ช่วยให้ผู้ดำเนินการ OpenClaw ค้นพบเซสชัน Codex แบบเนทีฟ และเมื่อปลอดภัย สามารถสร้างแบรนช์ภายในเครื่องผ่านพื้นผิว Chat ตามปกติของ OpenClaw
Codex App Server ยังคงเป็นเจ้าของเธรดและลูปโมเดล ส่วน OpenClaw จัดเตรียมแค็ตตาล็อกฟลีต, UI สำหรับผู้ดำเนินการที่ผ่านการยืนยันตัวตน, การผูกเซสชัน และการส่งผ่านช่องทาง

ฟีเจอร์นี้เป็นส่วนหนึ่งของ Plugin `codex` อย่างเป็นทางการ ไม่มี
Plugin Supervisor แยกต่างหากหรือการใช้งานโปรโตคอล Codex ชุดที่สอง

## ขอบเขตผลิตภัณฑ์

แค็ตตาล็อกจะลงทะเบียนทุกครั้งที่ Plugin Codex ทำงานอยู่ เว้นแต่จะปิดใช้งานการค้นพบเซสชันแบบเนทีฟอย่างชัดเจนด้วย:

```text
plugins.entries.codex.config.sessionCatalog.enabled = false
```

เปิดใช้งานเครื่องมือกำกับดูแลสำหรับเอเจนต์ด้วย:

```text
plugins.entries.codex.config.supervision.enabled = true
```

ผลิตภัณฑ์เริ่มต้นที่ใช้งานอยู่ได้รับการออกแบบให้มีขอบเขตเล็กกว่าแผนฟลีตระยะยาว:

- แสดงเฉพาะเธรด Codex ที่ไม่ได้เก็บถาวร
- จัดกลุ่มแถวภายในเครื่องและแถวจาก Node ที่จับคู่ซึ่งเลือกเข้าร่วม ตามข้อมูลประจำตัวโฮสต์ที่เสถียร
- สร้างแบรนช์ Chat ตามปกติที่ล็อกโมเดลจากเธรดที่จัดเก็บไว้หรือไม่ได้ใช้งานซึ่งอยู่ภายใน Gateway เริ่มเธรดชุดควบคุม Codex แบบเต็มเมื่อมีเทิร์นแรก หรือเปิด Chat ที่สร้างไว้สำหรับแบรนช์ก่อนหน้า
- เก็บเธรดที่จัดเก็บไว้หรือไม่ได้ใช้งานซึ่งอยู่ภายใน Gateway เป็นเอกสารถาวร หลังจากได้รับการยืนยันอย่างชัดเจนว่าไม่มีตัวดำเนินการอื่นเท่านั้น
- แสดงแหล่งข้อมูลภายในเครื่องที่ทำงานอยู่โดยไม่มีตัวควบคุมสำหรับแบรนช์ใหม่หรือการเก็บถาวร แต่ยังคงอนุญาตให้เปิด Chat ที่มีการกำกับดูแลอยู่แล้ว
- แสดงแถวใหม่ล่าสุดของแต่ละโฮสต์ในแถบด้านข้างหลัก เก็บแค็ตตาล็อกทั้งหมดไว้ในหน้าเซสชัน และรองรับการอ่านทรานสคริปต์แบบมีขอบเขตและแบ่งหน้าด้วยเคอร์เซอร์สำหรับแถวภายในเครื่องและแถวจาก Node ที่จับคู่
- แยกความล้มเหลวของแค็ตตาล็อกตามโฮสต์

แค็ตตาล็อกคือคอลเลกชันที่ไม่ได้เก็บถาวร แถวภายในแค็ตตาล็อกยังคงมีสถานะเทิร์นเป็น
ไม่ได้ใช้งาน, ทำงานอยู่, `notLoaded` หรือข้อผิดพลาดได้

การกำกับดูแลสำหรับเอเจนต์ยังคงเป็นแบบเลือกเข้าร่วม การเริ่มต้นใช้งานแบบมีคำแนะนำจะพยายามติดตั้งและเปิดใช้งานหลังจากตรวจพบการติดตั้ง Codex แบบเนทีฟสำเร็จ และแบ็กเอนด์การอนุมานที่เลือกผ่านการตรวจสอบแบบสด โดยไม่ขึ้นกับแบ็กเอนด์หลักที่ผู้ใช้เลือก การกำกับดูแลจะทำงานต่อเมื่อการตั้งค่า Plugin แบบฉวยโอกาสนั้นสำเร็จเท่านั้น Plugin ที่ถูกปิดใช้งานอย่างชัดเจน, การบล็อกตามนโยบาย หรือ
`supervision.enabled: false` ยังคงมีอำนาจเหนือเครื่องมือกำกับดูแล แต่
ไม่ได้ปิดใช้งานแค็ตตาล็อกเซสชันสำหรับผู้ดำเนินการ `sessionCatalog.enabled: false`
ปิดใช้งานการค้นพบสำหรับผู้ดำเนินการและคำสั่งแค็ตตาล็อกของ Node ที่จับคู่ แต่ผู้ให้บริการและชุดควบคุม Codex ยังคงทำงานอยู่

## ความเป็นเจ้าของ

Plugin `codex` เป็นเจ้าของพฤติกรรมทั้งหมดของ Codex App Server:

- การค้นพบเอ็นด์พอยต์และวงจรชีวิตการเชื่อมต่อ
- การเริ่มต้นโปรโตคอลและการตรวจสอบเวอร์ชัน
- การแสดงรายการ อ่าน ดำเนินการต่อ เก็บถาวร และจัดการเหตุการณ์ของเธรด
- บริดจ์สำหรับการอนุมัติและอินพุตจากผู้ใช้
- การผูกเธรดแบบเนทีฟเข้ากับเซสชัน OpenClaw
- การบังคับใช้โมเดลและชุดควบคุมเฉพาะ Codex หลังจากดำเนินการต่อ

Control UI และ Gateway ใช้บริการที่ Plugin เป็นเจ้าของนี้ โดยจะไม่อ่านไฟล์โรลเอาต์ของ Codex โดยตรง และไม่ใช้งานไคลเอ็นต์ App Server อีกชุดหนึ่ง

โทโพโลยีภายในเครื่องโดยค่าเริ่มต้นคือ:

```text
Codex Desktop -> App Server แบบ stdio ส่วนตัว -> โฮม Codex ของผู้ใช้
                                             ^
Plugin Codex ของ OpenClaw -> การเชื่อมต่อ App Server สำหรับการกำกับดูแล
  (ค่าเริ่มต้นคือ stdio ของโฮมผู้ใช้ที่มีการจัดการ โดยจะใช้การตั้งค่า appServer ที่ระบุไว้อย่างชัดเจน)
  -> แค็ตตาล็อกแหล่งข้อมูลแบบพาสซีฟและการอ่าน
  -> ปักหมุดสแนปช็อต -> แบรนช์แหล่ง appServer มาตรฐาน
  -> การแทรกประวัติที่มองเห็นได้และทุกเทิร์นของ Chat ที่มีการกำกับดูแลในภายหลัง

เซสชัน Codex ทั่วไปของ OpenClaw -> stdio ของโฮมเอเจนต์ที่มีการจัดการโดยค่าเริ่มต้น
  -> เธรดชุดควบคุมแบบเต็มทั่วไป -> Chat ของ OpenClaw และการส่งผ่านช่องทาง
```

การเปิดใช้งานการกำกับดูแลไม่เปลี่ยนชุดควบคุม Codex ตามปกติ โดยค่าเริ่มต้นยังคงจำกัดขอบเขตอยู่ที่เอเจนต์ การเชื่อมต่อสำหรับการกำกับดูแลที่แยกต่างหากมีค่าเริ่มต้นเป็น stdio ของโฮมผู้ใช้ที่มีการจัดการ ดังนั้นการดำเนินการกับแค็ตตาล็อกและสแนปช็อตจึงมองเห็นเธรดแบบเนทีฟที่จัดเก็บไว้ ระบบจะใช้การตั้งค่าการเชื่อมต่อ `appServer` ที่ระบุไว้อย่างชัดเจน เมื่อไม่ได้ตั้งค่า
`homeScope` การเชื่อมต่อสำหรับการกำกับดูแลจะแก้ค่าเป็น `"user"` สำหรับ stdio
หรือ Unix และ `"agent"` สำหรับ WebSocket ตั้งค่า `appServer.homeScope: "user"`
อย่างชัดเจนเฉพาะเมื่อต้องการให้ชุดควบคุมตามปกติใช้โฮม Codex แบบเนทีฟร่วมกันด้วย Chat ที่รับมาจากกลุ่ม Codex ในแถบด้านข้างเป็นข้อยกเว้น โดยการผูกการกำกับดูแลแบบส่วนตัวจะคงการอ่านแหล่งข้อมูล การสร้างแบรนช์มาตรฐาน และเทิร์นในภายหลังไว้บนการเชื่อมต่อสำหรับการกำกับดูแล สถานะแบบสดและความเป็นเจ้าของยังคงจำกัดอยู่ภายในกระบวนการ เธรดที่กระบวนการกำกับดูแลของ OpenClaw ไม่รู้จักจะเป็น `notLoaded`
แม้ว่า Codex Desktop กำลังเรียกใช้เธรดนั้นอยู่ก็ตาม

Codex มีดีมอนภายในเครื่องมาตรฐานแบบทดลอง ซึ่งมีสัญญาการบูตสแตรปที่จัดการโดยโปรแกรมติดตั้งแยกต่างหาก ฟีเจอร์นี้ต้องไม่บูตสแตรป อ้างสิทธิ์ หรือสันนิษฐานว่าจะใช้ดีมอนดังกล่าวโดยปริยาย

## ขั้นตอนการทำงานของแค็ตตาล็อก

เมธอดทั่วไปของ Gateway `sessions.catalog.list` จะส่งต่อไปยังผู้ให้บริการแค็ตตาล็อก `codex`
ซึ่งจะร้องขอ `archived: false` เสมอ และให้ App Server
ใช้ค่าเริ่มต้นสำหรับแหล่งข้อมูลเชิงโต้ตอบ ได้แก่ `cli`, `vscode`, Atlas และ ChatGPT โดยรวม:

1. ผลลัพธ์ `thread/list` ภายใน Gateway จาก App Server สำหรับการกำกับดูแล ซึ่งมีค่าเริ่มต้นเป็น stdio ของโฮมผู้ใช้ที่มีการจัดการ
2. ผลลัพธ์ `codex.appServer.threads.list.v1` จาก Node ที่เชื่อมต่อและเลือกเข้าร่วมแต่ละรายการ

การเลือกทรานสคริปต์ใช้ `thread/turns/list` ร่วมกับ `itemsView: "full"` ภายในเครื่อง หรือ
คำสั่ง `codex.appServer.thread.turns.list.v1` ที่มีการกำหนดเวอร์ชันบน
Node ที่เลือก แต่ละการตอบกลับมีเทิร์นที่คงอยู่ไม่เกิน 20 เทิร์น พร้อมเคอร์เซอร์เดินหน้า/ย้อนกลับแบบทึบ Control UI ร้องขอหน้าโดยเรียงจากใหม่ที่สุดก่อน แสดงแต่ละหน้าตามลำดับเวลา และเพิ่มหน้าเก่ากว่าไว้ด้านหน้า โดยจะไม่ย้อนกลับไปใช้
`thread/read` แบบไม่มีขอบเขต OpenClaw ยังปฏิเสธหน้ารายการที่ซีเรียลไลซ์แล้วซึ่งมีขนาดเกิน
20 MiB ก่อนที่จะส่งผ่านการขนส่งของ Node หรือ Gateway ได้

การใช้งาน Node ที่จับคู่แบบเนทีฟบน macOS รองรับเฉพาะค่าที่ไม่ได้ตั้ง/ค่าเริ่มต้น หรือ
`appServer.transport: "stdio"` ที่ระบุอย่างชัดเจน โดยมีขอบเขตการกำกับดูแลที่ไม่ได้ตั้ง/เป็นค่าเริ่มต้น หรือ
`appServer.homeScope: "user"` ที่ระบุอย่างชัดเจน ระบบจะส่ง `command`, `args`
ที่กำหนดค่าไว้ และ `clearEnv` ที่ปรับเป็นรูปแบบมาตรฐานแล้วไปยังกระบวนการลูก เมื่อใช้ `"unix"`, `"websocket"`
หรือ `homeScope: "agent"` ที่ระบุอย่างชัดเจน ระบบจะไม่ประกาศทั้งความสามารถของแค็ตตาล็อก
และคำสั่ง ทั้งยังปฏิเสธการเรียกใช้โดยตรงอย่างปลอดภัยด้วย ระบบต้องไม่เปิดเผยโฮม Codex ของผู้ใช้สำหรับการกำหนดค่าที่จำกัดขอบเขตอยู่ที่เอเจนต์ หรือแทนที่เอ็นด์พอยต์ที่ระบุไว้อย่างชัดเจนด้วย stdio ภายในเครื่อง

การฉายภาพแค็ตตาล็อกจะปรับตัวระบุ, ชื่อ, cwd, สถานะ, แฟล็กรอที่ทำงานอยู่, การประทับเวลา, แหล่งข้อมูล, ผู้ให้บริการโมเดล, เวอร์ชัน Codex และแบรนช์ Git ให้เป็นรูปแบบมาตรฐาน โดยจะไม่ส่งคืนตัวอย่างทรานสคริปต์, เทิร์น, พาธโรลเอาต์, พาธโฮม Codex,
รีโมต Git, SHA ของคอมมิต, เอ็นด์พอยต์ดิบ หรือข้อผิดพลาดดิบของ App Server การตอบกลับทรานสคริปต์จะมีเฉพาะหน้ารายการของ App Server ที่ร้องขออย่างชัดเจนและเคอร์เซอร์แบบทึบเท่านั้น

ความล้มเหลวของโฮสต์จะคงอยู่เฉพาะในผลลัพธ์ของแต่ละโฮสต์ Node ที่ออฟไลน์หรือ
App Server ภายในเครื่องที่ใช้งานไม่ได้จะไม่ลบโฮสต์ที่ปกติออกจากหน้า การเชื่อมต่อเป็นคุณสมบัติของโฮสต์ ไม่ใช่สถานะเธรด ผลลัพธ์ของโฮสต์ที่ล้มเหลวจะไม่มีแถวเซสชันใหม่ และจะไม่ฉาย `offline` ไปยังเธรดแบบเนทีฟ

Control UI ร้องขอการอัปเดตแค็ตตาล็อกแบบก้าวหน้า โฮสต์ภายในเครื่องหรือโฮสต์ที่จับคู่แต่ละรายการจะปรากฏเมื่อการแสดงรายการจาก App Server ของตนเสร็จสิ้น ส่วนการตอบกลับแบบรวมยังคงเป็นสแนปช็อตสำหรับความเข้ากันได้และการกู้คืน หน้าที่มองเห็นได้จะกระทบยอดหลังจากการเชื่อมต่อเปลี่ยนแปลง เมื่อได้รับโฟกัส และอย่างมากทุก 30 วินาที พร้อมรอบที่เร็วขึ้นหลังการเปลี่ยนแปลง ดังนั้นเซสชัน Codex แบบเนทีฟที่สร้างในไคลเอ็นต์อื่นจะถูกค้นพบในท้ายที่สุดโดยไม่ต้องนำเข้าไปยังพื้นที่จัดเก็บของ OpenClaw

การค้นพบแค็ตตาล็อกเป็นแบบพาสซีฟ การแสดงรายการหรืออ่านข้อมูลเมตาต้องไม่เรียก
`thread/resume`, สมัครให้ไคลเอ็นต์ OpenClaw รับคำขอเธรดแบบสด หรือตอบการอนุมัติ

การค้นหาจะค้นหาเฉพาะชื่อและไม่คำนึงถึงตัวพิมพ์เล็ก-ใหญ่ สำหรับหน้าแค็ตตาล็อกแต่ละหน้าที่ส่งคืน Gateway และ Mac ที่จับคู่จะสแกนหน้าแบบเนทีฟในจำนวนที่มีขอบเขต โดยไม่ส่งคำค้นไปยัง App Server เนื่องจากการค้นหาแบบเนทีฟอาจจับคู่ตัวอย่างทรานสคริปต์ด้วย เคอร์เซอร์แบบเนทีฟที่ส่งคืนช่วยให้ผู้เรียกดำเนินการสแกนต่อได้

## ขอบเขต CLI สำหรับผู้ดำเนินการ

Plugin ลงทะเบียนคำสั่งเชลล์ที่รองรับโดย Gateway จำนวนสามคำสั่ง:

```text
openclaw codex sessions [--search <text>] [--host <id>] [--limit <count>] [--cursor <cursor>] [--json] [gateway-options]
openclaw codex continue <thread-id> [--json] [gateway-options]
openclaw codex archive <thread-id> --confirm-no-other-runner [--json] [gateway-options]
```

`[gateway-options]` คือ `--url <url>`, `--token <token>`, `--timeout <ms>` และ
สวิตช์ `--expect-final` ที่สืบทอดมา การแสดงรายการเซสชันมีค่าเริ่มต้นเป็น 75,000 ms;
การดำเนินการต่อและการเก็บถาวรมีค่าเริ่มต้นเป็น 30,000 ms;
`--expect-final` ไม่มีผลเพิ่มเติมต่อ RPC แบบยูนารีเหล่านี้ การค้นหาเซสชันจะค้นหาเฉพาะชื่อและไม่คำนึงถึงตัวพิมพ์เล็ก-ใหญ่ การตอบกลับแต่ละครั้งจะสแกนสายโซ่หน้าแบบเนทีฟที่มีขอบเขต และ `--cursor` จะดำเนินการต่อไปยังผลลัพธ์ที่เก่ากว่า ขีดจำกัดมีค่าเริ่มต้นเป็น 50 ต่อโฮสต์
และรับค่าได้ตั้งแต่ 1 ถึง 100 ส่วนเคอร์เซอร์ต้องมีปลายทาง `--host`
ที่เสถียรหนึ่งรายการ ไม่มีคำสั่งใดรับตัวเลือก archived/include-archived เฉพาะ `sessions` เท่านั้นที่กำหนดเป้าหมายไปยังโฮสต์ที่จับคู่ได้;
`continue` และ `archive` จะส่ง `hostId: "gateway:local"` เสมอ และการเก็บถาวร
ต้องใช้แฟล็กยืนยันอย่างชัดเจน

เนมสเปซเชลล์ไม่ใช่เนมสเปซรันไทม์ `/codex` ภายในแชต โดยเฉพาะ
`/codex sessions --host <node>` จะแสดงรายการไฟล์เซสชัน Codex CLI บน Node หนึ่งรายการ,
`/codex threads` จะแสดงรายการเธรด App Server สำหรับการเชื่อมต่อของบทสนทนาปัจจุบัน
และ `/codex resume` หรือ `/codex bind` จะแก้ไขการผูกของบทสนทนานั้น
คำสั่งเหล่านี้ไม่แทนที่ `sessions.catalog.continue` และไม่มีคำสั่งรันไทม์
`/codex continue` หรือ `/codex archive`

## การดำเนินการต่อภายในเครื่อง

สำหรับแถวที่จัดเก็บไว้หรือไม่ได้ใช้งานซึ่งอยู่ภายใน Gateway นั้น UI จะเรียก
`sessions.catalog.continue` ด้วย `catalogId: "codex"` พร้อมรหัสโฮสต์และเธรด
Plugin จะ:

1. ใช้ Chat ที่มีการกำกับดูแลเดิมซ้ำเมื่อแหล่งข้อมูลมี Chat อยู่แล้ว
2. มิฉะนั้น จะฉายประวัติของผู้ใช้และผู้ช่วยที่มีขอบเขตจนถึงเทิร์นที่คงอยู่และสิ้นสุดล่าสุดของแหล่งข้อมูล (เสร็จสมบูรณ์ ถูกขัดจังหวะ หรือล้มเหลว) ไปยัง Chat ใหม่ของ OpenClaw และบันทึกแบรนช์ชุดควบคุมที่รอดำเนินการ
3. จัดเก็บนโยบายล็อกโมเดลเฉพาะ Codex ที่รอดำเนินการ ไม่ใช่การเลือกโมเดลหรือผู้ให้บริการที่เป็นรูปธรรม พร้อมขอบเขตการเชื่อมต่อสำหรับการกำกับดูแลแบบส่วนตัว และส่งคืน `sessionKey` ของ OpenClaw

การฉายประวัติจะเลือกส่วนท้ายใหม่ที่สุดของข้อความจากผู้ใช้และผู้ช่วยที่มองเห็นได้ โดยมีขีดจำกัดตายตัวที่ 200 ข้อความ, ข้อความ UTF-8 รวม 512 KiB และ 64 KiB ต่อข้อความ ระบบจะแทนที่อินพุตรูปภาพและรูปภาพภายในเครื่องด้วย
`[Image attachment]` โดยไม่คัดลอกเพย์โหลดหรือพาธรูปภาพ และละเว้นการให้เหตุผล,
การเรียกเครื่องมือ และผลลัพธ์จากเครื่องมือ

UI จะนำทางไปยัง Chat ตามปกติด้วยคีย์เซสชันนั้น ขณะนี้ยังไม่มีเธรดชุดควบคุมมาตรฐาน ในเทิร์นแรกของ Chat ตามปกติ ชุดควบคุมจะติดตั้งตัวจัดการการอนุมัติ การขอข้อมูล เหตุการณ์ และการส่งมอบของ Codex จริง จากนั้น:

1. ใช้การเชื่อมต่อสำหรับการกำกับดูแลเพื่อเรียก `thread/fork` แบบเนทีฟโดยไม่เขียนทับโมเดลหรือผู้ให้บริการ และปักหมุดสแนปช็อตแหล่งข้อมูลที่คงอยู่ สถานะ `ConfigManager` ปัจจุบันของ Codex จะเลือกโมเดลและผู้ให้บริการ และการตอบกลับจากการฟอร์กจะรายงานคู่ที่ใช้จริง หากโมเดลแตกต่างจากโมเดลล่าสุดที่บันทึกไว้ในแหล่งข้อมูล Codex จะแสดงคำเตือนความแตกต่างของโมเดลตามปกติ
2. บนการเชื่อมต่อเดียวกันนั้น เริ่มเธรดชุดควบคุม Codex แบบเต็มมาตรฐานด้วย
`threadSource: "appServer"`, cwd, นโยบาย, การกำหนดค่า และสภาพแวดล้อมของ OpenClaw,
พื้นผิวเครื่องมือของชุดควบคุม OpenClaw แบบเต็ม และโมเดลกับผู้ให้บริการที่การฟอร์กส่งคืนสำหรับการเริ่มต้นครั้งแรกนี้อย่างตรงกัน
3. แทรกประวัติผู้ใช้และผู้ช่วยที่มองเห็นได้ซึ่งมีขอบเขตผ่านการเชื่อมต่อนั้น คอมมิตการผูกมาตรฐานโดยไม่ละทิ้งขอบเขตการกำกับดูแล เรียกใช้เทิร์น และเก็บฟอร์กชั่วคราวเป็นเอกสารถาวร

ก่อนเทิร์นแรก Chat จะเป็นสาขาที่รอดำเนินการและถูกล็อก โดยมีมิเรอร์
ประวัติที่มองเห็นได้ หลังจากนั้น ทุกเทิร์นของโมเดลจะทำงานผ่านเธรด harness
Codex มาตรฐานบนการเชื่อมต่อการกำกับดูแล สาขานี้ไม่ใช่สำเนา rollout แบบเนทีฟ
ที่สมบูรณ์ โดยจงใจละเว้นการให้เหตุผลของต้นทาง การเรียกใช้เครื่องมือ และผลลัพธ์
จากเครื่องมือ หากการตรึงสแนปช็อตหรือการสร้างเธดมาตรฐานล้มเหลว สาขาที่รอดำเนินการ
จะยังลองใหม่ได้ การแข่งขันกันผูกข้อมูล การปิดใช้การกำกับดูแล หรือการเชื่อมต่อ
การกำกับดูแลที่ไม่พร้อมใช้งานหรือไม่ตรงกัน จะปฏิเสธการทำงานก่อนเทิร์นเริ่ม
แทนที่จะย้อนกลับไปใช้ harness ปกติของโฮมเอเจนต์

สิ่งนี้รับประกันการเลือกที่ Codex เป็นเจ้าของ ไม่ใช่การคงโมเดลในอดีตของต้นทางไว้
คู่ค่าที่ fork ส่งคืนจะใช้เริ่มเธรดมาตรฐาน และ Codex จะคงโมเดลและผู้ให้บริการ
แบบเนทีฟของเธรดนั้นไว้ การกลับมาทำงานต่อภายหลังจะไม่ระบุค่าลบล้างโมเดลและ
ผู้ให้บริการของ OpenClaw ดังนั้น Codex จะคืนค่าคู่ที่คงไว้ หากการควบคุม Codex
แบบเนทีฟแยกต่างหากเปลี่ยนเธรดมาตรฐาน OpenClaw จะยอมรับการเลือกแบบเนทีฟที่คงไว้
โมเดล OpenClaw ชั้นนอกและสายโซ่สำรองจะไม่เข้ามาแทนที่คู่นั้น

การเปลี่ยนโมเดล การลบเซสชัน และการรีเซ็ตเซสชัน/สร้างใหม่ จะปฏิเสธการทำงาน
สำหรับ Chat ที่อยู่ภายใต้การกำกับดูแลและล็อกโมเดล การแก้ไข `/codex model <model>`, `/codex
bind`, `/codex resume` (รวมถึง Node `--bind here`) และ `/codex detach` หรือ
`/codex unbind` จะปฏิเสธการทำงานเช่นกัน เนื่องจากเป็นการแทนที่หรือล้างการผูกข้อมูล ส่วนคำขอ
`/codex model` และ `/codex fast`, `/codex permissions` และ `/codex
threads` ยังคงใช้งานได้ เครื่องมือเอเจนต์ `codex_threads` ไม่สามารถแนบ
fork ใหม่หรือเก็บเธรดเนทีฟที่ผูกไว้เข้าคลังได้ การอ่านรายการและเฉพาะเมทาดาทา
ยังคงใช้งานได้ ฟิลด์ทรานสคริปต์ต้องใช้ `supervision.allowRawTranscripts` ขณะที่
การเปลี่ยนชื่อ การนำออกจากคลัง fork ที่แยกออกมา และการเก็บเธรดที่ไม่เกี่ยวข้อง
เข้าคลังต้องใช้ `supervision.allowWriteControls` ไม่มีตัวเลือกใดแทนที่การผูกข้อมูลที่ล็อกไว้ได้
มิฉะนั้น การลบหรือรีเซ็ตรายการ OpenClaw จะทิ้งการผูกข้อมูลแบบเนทีฟ
และสร้างหรือเปิดทางให้มีเธรดทั่วไปอยู่เบื้องหลังเซสชันที่ดูเหมือน Codex
ดังนั้นการบำรุงรักษาการเก็บรักษาข้อมูลจึงคงรายการที่ล็อกโมเดลไว้ แม้รายการเหล่านั้น
จะเกินขีดจำกัดอายุ จำนวน หรือโควตาดิสก์ตามปกติ การปิดใช้หรือถอนการติดตั้ง
Plugin เจ้าของจะยังคงสถานะล็อกและเครื่องหมายความเป็นเจ้าของ Plugin ไว้ Chat
จะยังไม่พร้อมใช้งานและปฏิเสธการทำงานจนกว่าจะเปิดใช้ Plugin เดิมอีกครั้ง
การล้างข้อมูลจะไม่แปลง Chat ให้เป็นเซสชันโมเดลปกติ

การดำเนินการนี้จะไม่กลับมาทำงานต่อหรือแก้ไขต้นทาง fork ชั่วคราวจะตรึง
สแนปช็อต โดยไม่ใช่เธรดทำงานต่อแบบถาวร การเริ่มเธรด harness มาตรฐาน
ที่แยกต่างหากในเทิร์นแรก ป้องกันไม่ให้ OpenClaw กลายเป็นผู้เขียนต้นทางที่แข่งขันกัน
เพียงเพราะสถานะภายในโปรเซสมองไม่เห็นเทิร์นที่ Desktop เป็นเจ้าของ มิเรอร์ประวัติ
ที่มองเห็นได้และสแนปช็อตที่ตรึงไว้อาจละเว้นงานที่ยังไม่เสร็จสิ้นในต้นทางที่กำลังทำงาน
ต้นทาง CLI, VS Code, Atlas หรือ ChatGPT ดั้งเดิมยังมีสิทธิ์ปรากฏทั้งในแคตตาล็อก
แบบเนทีฟและแคตตาล็อก OpenClaw สาขามาตรฐานยังคงเป็นเธรด Codex แบบเนทีฟ
ในพื้นที่จัดเก็บการกำกับดูแล แต่ไคลเอนต์แบบเนทีฟอาจกรองชนิดต้นทาง
`appServer` ของเธรดนั้น ดังนั้นการมองเห็นใน Codex Desktop จึงไม่ใช่สัญญา

## ลักษณะการทำงานของการเก็บเข้าคลัง

สำหรับแถวที่จัดเก็บหรือไม่ได้ใช้งานภายใน Gateway `sessions.catalog.archive` ที่มี
`catalogId: "codex"` ต้องได้รับ
`confirmNoOtherRunner: true` อย่างชัดแจ้ง อ่านสถานะภายในโปรเซสปัจจุบันใหม่
ดำเนินการต่อเฉพาะสำหรับ `idle` หรือ `notLoaded` เรียก `thread/archive` แบบเนทีฟ
และส่งคืนความสำเร็จหลังจาก Codex ยอมรับการดำเนินการแล้วเท่านั้น จากนั้นแถวนั้น
จะออกจากแคตตาล็อกที่ไม่ได้เก็บเข้าคลัง

สถานะกำลังทำงานหรือข้อผิดพลาดจากการอ่านใหม่จะปฏิเสธการเก็บเข้าคลัง เช่นเดียวกับ
สาขาที่อยู่ภายใต้การกำกับดูแลซึ่งกำลังเริ่มต้นหรือรอดำเนินการจากต้นทาง โดยเทิร์นแรก
ของ Chat ต้องสร้างสาขามาตรฐานให้เป็นรูปธรรมก่อนจึงจะเก็บต้นทางเข้าคลังได้
เจ้าของการผูกข้อมูล OpenClaw ที่ทราบว่ากำลังทำงานสำหรับเป้าหมายที่ตรงกันทุกประการ
หรือรายการสืบทอดที่สร้างขึ้นและยังไม่ได้เก็บเข้าคลัง จะปฏิเสธการเก็บเข้าคลังเช่นกัน
OpenClaw แบ่งหน้าความสัมพันธ์ทดลอง `thread/list ancestorThreadId` ของ Codex
และปฏิเสธการทำงานเมื่อเกิดข้อผิดพลาดของคำขอหรือการตอบกลับ วงจรของเคอร์เซอร์
หรือเธรด และการใช้ขีดจำกัดความปลอดภัยจนหมด การเก็บเข้าคลังแบบเนทีฟสามารถ
ปิดงานพาเรนต์และงานสืบทอดที่โหลดอยู่ได้ ดังนั้นการเก็บเข้าคลังจึงไม่ใช่ทางลัด
สำหรับการขัดจังหวะ การอ่าน การแจกแจงรายการสืบทอด และการเรียกเก็บเข้าคลัง
ไม่ได้เป็นอะตอมมิก ไคลเอนต์อิสระยังสามารถเป็นเจ้าของหรือเริ่มงานบนแถว
ที่ดูเหมือนไม่ได้ใช้งานหรือเป็น `notLoaded` ภายในเครื่องได้ การยืนยันว่าไม่มี
ตัวทำงานอื่นครอบคลุมไคลเอนต์ที่ไม่ทราบและการแข่งขันดังกล่าว จนกว่า Codex
จะมีการเก็บเข้าคลังแบบมีเงื่อนไขหรือ lease ข้ามโปรเซส ห้ามเก็บเข้าคลังผ่าน Node
ที่จับคู่ไว้

ไม่มีมุมมองรายการที่เก็บเข้าคลังในแคตตาล็อก Codex เธรดที่คืนค่าด้วย
`thread/unarchive` ในพื้นผิว Codex อื่นที่เจ้าของอนุญาต จะกลับมามีสิทธิ์
ปรากฏในแคตตาล็อกที่ไม่ได้เก็บเข้าคลังอีกครั้ง

## ความปลอดภัยของเธรดที่กำลังทำงาน

Codex จัดลำดับการแก้ไขเธรดในหมู่ไคลเอนต์ของ App Server เดียวกัน แต่ไม่ได้
เปิดเผย lease แบบเอกสิทธิ์สำหรับตัวทำงานหรือเจ้าของการอนุมัติข้ามโปรเซส
App Server แบบ stdio ที่เป็นอิสระต่อกันสามารถต่อท้าย rollout เดียวกันได้
ขณะที่แต่ละรายการมองเห็นเฉพาะสถานะในหน่วยความจำของตนเอง คำขออนุมัติยังสามารถ
ส่งถึงผู้สมัครรับข้อมูลทุกรายของเซิร์ฟเวอร์หนึ่ง โดยการตอบกลับที่ถูกต้องรายการแรก
จะทำให้คำขอเสร็จสมบูรณ์

ดังนั้น:

- ไคลเอนต์แคตตาล็อกแบบพาสซีฟจะไม่สมัครรับข้อมูลหรือปฏิเสธการอนุมัติโดยอัตโนมัติ
- แถวที่ขณะนี้รายงานว่ากำลังทำงานจะไม่แสดงทั้งสาขาใหม่และ Archive
- ต้นทางที่ยังไม่ได้แมปจะกลายเป็นสาขาประวัติที่มองเห็นได้ ซึ่งเธรด harness
  มาตรฐานของสาขานั้นจะไม่กลับมาทำงานต่อต้นทาง
- `notLoaded` จะแสดงเป็นไม่ทราบกิจกรรม และเก็บเข้าคลังได้หลังจาก
  การยืนยันอย่างมีข้อมูลว่าไม่มีตัวทำงานอื่นเท่านั้น
- การเก็บเข้าคลังภายในเครื่องต้องใช้การยืนยันดังกล่าวพร้อมการอ่าน `idle` หรือ `notLoaded`
  ใหม่ โดยยอมรับการแข่งขันระดับโปรโตคอลระหว่างการอ่านและการเก็บเข้าคลัง

การขัดจังหวะและการส่งมอบระหว่างหลายไคลเอนต์เป็นการตัดสินใจด้านผลิตภัณฑ์
ในอนาคต การแสดงแถวที่กำลังทำงานไม่ได้หมายความถึงความสามารถเหล่านี้

## ขอบเขตของ Node ที่จับคู่

ขณะนี้การเรียกใช้ Node รองรับเฉพาะคำขอ/การตอบกลับ โดยสามารถส่งคืนเมทาดาทา
แคตตาล็อกแบบมีขอบเขตและหน้าของเทิร์นในทรานสคริปต์ได้อย่างปลอดภัย แต่ไม่สามารถ
ส่งสตรีมเหตุการณ์ระยะยาว คำขออนุมัติ การเรียกใช้เครื่องมือ การยกเลิก และเดลตาของ
ผู้ช่วยที่การทำงานของ harness Codex ต้องใช้ได้

ดังนั้นสัญญาของ Node จึงรองรับรายการและหน้าของเทิร์นในทรานสคริปต์ แถวระยะไกล
ยังอ่านได้ แต่ **Continue** และ **Archive** ไม่พร้อมใช้งาน โดยไม่คำนึงถึงสถานะ
ไม่ได้ใช้งาน การทำงานต่อจากระยะไกลจริงต้องใช้ตัวทำงานฝั่ง Node และบริดจ์สตรีมมิง
ที่รักษาค่าคงที่ด้านการอนุมัติและการผูกข้อมูลเช่นเดียวกับ harness ภายในเครื่อง

## สิทธิ์

คอมพิวเตอร์แต่ละเครื่องเลือกเข้าร่วมภายในเครื่อง การเปิดใช้ Gateway ไม่ได้อนุญาต
ให้ Node อื่นอ่านเมทาดาทา Codex ของเครื่องนั้น ความสามารถของ Node ต้องผ่าน
การจับคู่ตามปกติและการอนุมัตินโยบายคำสั่ง

การแสดงรายการทั้งกลุ่มและการดูทรานสคริปต์ใช้ขอบเขต Gateway
`operator.write` เนื่องจากเรียกใช้ Node ที่จับคู่ การทำงานต่อและการเก็บเข้าคลัง
ภายในเครื่องเป็นการดำเนินการของโอเปอเรเตอร์ที่ผ่านการยืนยันตัวตน และยังคงอยู่ภายใต้
การตรวจสอบโฮสต์และสถานะ

การเข้าถึงโดยเอเจนต์อัตโนมัติและ MCP แบบสแตนด์อโลนแยกจากกัน สัญญาเครื่องมือ
`codex_endpoint_probe`, `codex_sessions_list`, `codex_session_read`,
`codex_session_send` และ `codex_session_interrupt` ที่ส่งมอบยังคงเป็นของ
Plugin `codex` เมื่อเปิดใช้การกำกับดูแล การอ่านทรานสคริปต์ดิบ `codex_threads`
และฟิลด์รายการที่ได้มาจากทรานสคริปต์ต้องใช้
`supervision.allowRawTranscripts` ด้วย ส่วน fork การเปลี่ยนชื่อ การเก็บเข้าคลัง
หรือการนำออกจากคลังทุกครั้งผ่าน `codex_threads` ต้องใช้ `supervision.allowWriteControls`
นโยบายทั้งสองปิดใช้เป็นค่าเริ่มต้น

## ความเข้ากันได้

`openclaw doctor --fix` ย้ายการกำหนดค่า `plugins.entries.codex-supervisor`
ที่ส่งมอบแล้ว รวมถึงเอนด์พอยต์และนโยบายทรานสคริปต์/การเขียน ตลอดจนการอ้างอิง
รายการอนุญาต/ปฏิเสธของ Plugin ไปยัง
`plugins.entries.codex.config.supervision` ค่าปลายทางมาตรฐานที่ระบุอย่างชัดแจ้ง
จะชนะเมื่อเกิดข้อขัดแย้ง โค้ดรันไทม์ใช้เฉพาะรูปแบบ Plugin `codex`
มาตรฐานหลังการย้ายข้อมูล

Plugin อย่างเป็นทางการคงเครื่องมือความเข้ากันได้ของ Supervisor ไว้ห้ารายการพอดี:
`codex_endpoint_probe`, `codex_sessions_list`, `codex_session_read`,
`codex_session_send` และ `codex_session_interrupt` รายการเซสชันจะแสดงเฉพาะ
รายการที่โหลดอยู่โดยค่าเริ่มต้น และไม่มีพารามิเตอร์ `loaded_only`
`include_stored: true` เพิ่มแถวฐานข้อมูลสถานะที่ไม่ได้เก็บเข้าคลัง โดยจำกัดต่อ
เอนด์พอยต์ด้วย `max_stored_sessions` (ค่าเริ่มต้น 200 ช่วงที่ยอมรับได้ 1 ถึง 1,000)
แถวที่โหลดอยู่ไม่ถูกจำกัดด้วยการตั้งค่านั้น ฟิลด์และการอ่านที่ได้มาจากทรานสคริปต์
ยังคงถูกควบคุมด้วย `allowRawTranscripts` ส่วนการส่งและการขัดจังหวะยังคง
ถูกควบคุมด้วย `allowWriteControls`

การส่งเพื่อความเข้ากันได้จะไม่เริ่มหรือกลับมาทำงานต่อเธรดที่ไม่ได้ใช้งาน
`mode: "start"` จะถูกปฏิเสธเสมอ ส่วน `"auto"` และ
`"steer"` ใช้นำทางเฉพาะเทิร์นที่กำลังทำงานและอ่านได้เท่านั้น
การขัดจังหวะต้องมีเทิร์นที่กำลังทำงานและอ่านได้เช่นกัน การทำงานต่อจากสถานะ
ไม่ได้ใช้งานจะส่งไปยังแคตตาล็อก Codex แบบเนทีฟ เพื่อให้ harness แบบเต็ม
เป็นเจ้าของการอนุมัติ เครื่องมือ และการผูกข้อมูล อะแดปเตอร์ MCP รุ่นเก่าแบบ
สแตนด์อโลนจะแก้ไขเครื่องมือเดียวกันเหล่านี้จาก Plugin อย่างเป็นทางการ และเป็น
เส้นทางเดียวที่ใช้ตัวแปรสภาพแวดล้อมของนโยบายรุ่นเก่าที่ยังคงไว้

UI แคตตาล็อกของเดือนกรกฎาคม เมธอด Gateway ความสามารถของ Node และการลงทะเบียน
CLI ยังไม่เคยส่งมอบภายใต้รหัส Plugin เดิม รายการเหล่านี้ย้ายไปอยู่ภายใต้
ความเป็นเจ้าของของ `codex` โดยตรง โดยไม่มี facade รันไทม์ชั้นที่สอง

## งานในอนาคต

- ตัวทำงานสตรีมมิงฝั่ง Node และบริดจ์เหตุการณ์สำหรับการทำงานต่อจากระยะไกล
- lease ของตัวทำงานและเจ้าของการอนุมัติที่ชัดเจนสำหรับการส่งมอบระหว่างไคลเอนต์พร้อมกัน
- การเก็บเข้าคลังจากระยะไกลหลังมี lease ความเป็นเจ้าของตัวทำงานหรือการกั้นที่เทียบเท่า
- การขัดจังหวะและการสังเกตเซสชันที่กำลังทำงานอย่างละเอียดขึ้น
- การส่งมอบที่ผ่านการตรวจสอบระหว่าง Codex Desktop, CLI และ OpenClaw

การเรียกดูรายการที่เก็บเข้าคลังไม่ใช่ส่วนหนึ่งของแถบด้านข้างการกำกับดูแลที่วางแผนไว้
พื้นผิว Codex แบบเนทีฟยังคงเป็นเส้นทางการกู้คืนสำหรับเธรดที่เก็บเข้าคลัง

## การทดสอบการยอมรับ

- การเปิดใช้การควบคุมดูแลจะแสดงรายการเซสชันภายในเครื่องที่ยังไม่ได้เก็บถาวร
- เซสชันที่เก็บถาวรแล้วจะไม่ปรากฏในการตอบกลับของแค็ตตาล็อกหรือ UI
- โฮสต์ที่ทำงานเป็นปกติยังคงมองเห็นได้เมื่อโฮสต์อื่นล้มเหลว ส่วนโฮสต์ที่ไม่พร้อมใช้งาน
  จะไม่ส่งคืนแถวข้อมูลใหม่ แทนที่จะสร้างสถานะเซสชันออฟไลน์ขึ้นมาเอง
- แถวภายในเครื่องที่จัดเก็บไว้หรือไม่มีการใช้งานจะสร้างสำเนาสะท้อน Chat ที่ล็อก
  โมเดล/รันไทม์ไว้เฉพาะ Codex เท่านั้น เทิร์นแรกจะตรึงสแนปช็อตชั่วคราวและเริ่มเธรด
  ฮาร์เนสเต็มรูปแบบมาตรฐาน และการกด Continue ซ้ำจะเปิด Chat ที่มีอยู่
- เทิร์นแรกจะไม่ส่งค่าที่ใช้แทนโมเดล/ผู้ให้บริการในการแยกสแนปช็อต และตรึง
  การเริ่มต้นมาตรฐานไว้กับคู่ที่ Codex ส่งคืนมาอย่างแม่นยำ แม้ Codex จะเตือน
  ว่าโมเดลปัจจุบันแตกต่างจากโมเดลล่าสุดที่บันทึกไว้ของต้นทาง
- การเชื่อมโยงภายใต้การควบคุมดูแลทั้งที่รอดำเนินการและยืนยันแล้วจะใช้การเชื่อมต่อการควบคุมดูแลสำหรับ
  การเข้าถึงต้นทาง การสร้างแบรนช์มาตรฐาน และทุกเทิร์นภายหลัง ส่วนเซสชัน
  Codex ทั่วไปยังคงมีขอบเขตระดับเอเจนต์
- การดำเนินการต่อภายหลังจะไม่ส่งค่าที่ใช้แทนโมเดล/ผู้ให้บริการของ OpenClaw โดยจะคงการเลือก
  ที่จัดเก็บไว้มาตรฐานของ Codex ยอมรับการเปลี่ยนแปลงแบบเนทีฟที่เกิดขึ้นแยกต่างหากกับเธรดนั้น
  และจะไม่นำโมเดล OpenClaw ชั้นนอกหรือสายโซ่สำรองมาใช้แทน
- การปิดใช้การควบคุมดูแลหรือการสูญเสียวัฏจักรการเชื่อมโยง/การเชื่อมต่อจะปฏิเสธการดำเนินการ
  แทนที่จะย้าย Chat ไปยังฮาร์เนสในโฮมของเอเจนต์ทั่วไป
- ไม่สามารถลบ Chat ที่ถูกล็อกโมเดลภายใต้การควบคุมดูแลได้ ขณะที่ Chat นั้นยังปกป้อง
  การเชื่อมโยงแบบเนทีฟ
- Chat จะทำสำเนาสะท้อนข้อความของผู้ใช้และผู้ช่วยไม่เกิน 200 ข้อความ รวมทั้งหมดไม่เกิน 512 KiB และ
  ไม่เกิน 64 KiB ต่อข้อความ รูปภาพจะกลายเป็นตัวแทนข้อความ ส่วนกระบวนการให้เหตุผลของต้นทาง การเรียกใช้เครื่องมือ
  ผลลัพธ์จากเครื่องมือ เพย์โหลดรูปภาพ และพาธภายในเครื่องจะไม่ถูกโคลน
- ขั้นตอนการสร้างแบรนช์จะไม่ดำเนินเธรดต้นทางต่อ
- ต้นทางเดิมยังคงมีสิทธิ์ปรากฏในทั้งสองแค็ตตาล็อก แบรนช์แบบเนทีฟมาตรฐาน
  ใช้ชนิดต้นทาง `appServer` และไม่รับประกันว่าจะปรากฏใน
  Codex Desktop
- ต้นทางภายในเครื่องที่กำลังใช้งานไม่สามารถสร้างแบรนช์หรือเก็บถาวรได้ แต่ยังคงเปิด
  Chat ภายใต้การควบคุมดูแลที่มีอยู่ได้
- แถวที่ไม่ทราบสถานะกิจกรรมสามารถสร้างแบรนช์ได้โดยไม่ต้องยืนยัน แต่การเก็บถาวรต้องมี
  การยืนยันอย่างชัดเจนว่าไม่มีตัวรันอื่น
- ต้นทางที่มีแบรนช์ภายใต้การควบคุมดูแลซึ่งกำลังเริ่มต้นหรือรอดำเนินการไม่สามารถเก็บถาวรได้
  จนกว่าเทิร์นแรกของ Chat จะทำให้แบรนช์มาตรฐานเกิดขึ้นจริง
- เจ้าของการเชื่อมโยงที่ทราบว่ากำลังใช้งานสำหรับเป้าหมายที่ตรงกันทุกประการหรือรายการสืบทอดที่สร้างขึ้น
  ซึ่งยังไม่ได้เก็บถาวรจะขัดขวางการเก็บถาวร หากการแจกแจงรายการสืบทอดล้มเหลว ระบบจะปฏิเสธการดำเนินการ และ
  การยืนยันอย่างชัดเจนยังคงมีหน้าที่รับผิดชอบต่อไคลเอนต์ที่ไม่ทราบสถานะและ
  ภาวะแข่งขันระหว่างการตรวจสอบสถานะกับการเก็บถาวร
- การเก็บถาวรภายในเครื่องที่ยืนยันแล้วว่าอยู่ในสถานะจัดเก็บหรือไม่มีการใช้งานจะนำแถวนั้นออกหลังจากการดำเนินการแบบเนทีฟสำเร็จ
- แถวของโหนดที่จับคู่แล้วยังคงมองเห็นได้โดยไม่มี Continue หรือ Archive
- การแสดงรายการแบบพาสซีฟจะไม่สมัครรับหรือส่งคำตอบต่อการอนุมัติเธรด
- การกำหนดค่า Supervisor แบบเดิมจะย้ายไปยังรูปแบบการกำหนดค่า Codex มาตรฐาน
- โดยค่าเริ่มต้น รายการแบบเดิมจะใช้สำหรับการโหลดเท่านั้น การแจกแจงรายการที่จัดเก็บไว้จะเป็นไปตาม
  ขีดจำกัดต่อเอนด์พอยต์ และการส่งเพื่อความเข้ากันได้จะไม่เริ่มหรือดำเนินเธรดที่ไม่มีการใช้งานต่อ