---
read_when:
    - คุณต้องการอัปเดตซอร์สโค้ดที่เช็กเอาต์ไว้อย่างปลอดภัย
    - คุณกำลังดีบักเอาต์พุตหรือตัวเลือกของ `openclaw update`
    - คุณจำเป็นต้องเข้าใจลักษณะการทำงานของรูปแบบย่อ `--update`
summary: เอกสารอ้างอิง CLI สำหรับ `openclaw update` (การอัปเดตซอร์สที่ค่อนข้างปลอดภัย + การรีสตาร์ต Gateway โดยอัตโนมัติ)
title: อัปเดต
x-i18n:
    generated_at: "2026-07-16T18:53:32Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: b46696f6b9cba5c318f870bcb6c5ea8e0652940968da2ad85e86709fe4c11146
    source_path: cli/update.md
    workflow: 16
---

# `openclaw update`

อัปเดต OpenClaw และสลับระหว่างช่องทาง stable/extended-stable/beta/dev

หากติดตั้งผ่าน **npm/pnpm/bun** (การติดตั้งแบบ global ที่ไม่มีข้อมูลเมตาของ git)
การอัปเดตจะดำเนินการผ่านขั้นตอนของตัวจัดการแพ็กเกจที่อธิบายไว้ใน
[การอัปเดต](/th/install/updating)

## การใช้งาน

```bash
openclaw update
openclaw update status
openclaw update repair
openclaw update wizard
openclaw update --channel extended-stable
openclaw update --channel beta
openclaw update --channel dev
openclaw update --tag beta
openclaw update --tag main
openclaw update --dry-run
openclaw update --no-restart
openclaw update --yes
openclaw update --acknowledge-clawhub-risk
openclaw update --json
openclaw --update
```

`openclaw --update` จะถูกเขียนใหม่เป็น `openclaw update` (มีประโยชน์สำหรับเชลล์และ
สคริปต์ตัวเรียกใช้งาน)

## ตัวเลือก

| แฟล็ก                                             | คำอธิบาย                                                                                                                                                                                                                                                                                                                                  |
| ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--no-restart`                                   | ข้ามการรีสตาร์ตบริการ Gateway หลังจากอัปเดตสำเร็จ การอัปเดตผ่านตัวจัดการแพ็กเกจที่มีการรีสตาร์ตจะตรวจสอบว่าบริการที่รีสตาร์ตแล้วรายงานเวอร์ชันที่คาดไว้ก่อนที่คำสั่งจะสำเร็จ                                                                                                                                               |
| `--channel <stable\|extended-stable\|beta\|dev>` | กำหนดช่องทางอัปเดตและบันทึกไว้หลังจากอัปเดตคอร์สำเร็จ extended-stable ใช้ได้กับแพ็กเกจเท่านั้น                                                                                                                                                                                                                                            |
| `--tag <dist-tag\|version\|spec>`                | แทนที่เป้าหมายแพ็กเกจสำหรับการอัปเดตครั้งนี้เท่านั้น ไม่สามารถใช้ร่วมกับช่องทาง `extended-stable` ที่มีผลอยู่ ซึ่งบังคับให้ใช้เป้าหมายแบบระบุแน่นอนที่ผ่านการตรวจสอบแล้ว สำหรับการติดตั้งแพ็กเกจอื่น `main` จะจับคู่กับ `github:openclaw/openclaw#main`; ข้อกำหนดแหล่งที่มาของ GitHub/git จะถูกบรรจุเป็น tarball ชั่วคราวก่อนการติดตั้ง npm แบบ global ที่แบ่งเป็นขั้นตอน |
| `--dry-run`                                      | แสดงตัวอย่างการดำเนินการที่วางแผนไว้ (ช่องทาง/แท็ก/เป้าหมาย/ขั้นตอนการรีสตาร์ต) โดยไม่เขียนการกำหนดค่า ติดตั้ง ซิงค์ Plugin หรือรีสตาร์ต                                                                                                                                                                                                                |
| `--json`                                         | แสดง JSON `UpdateRunResult` ที่เครื่องอ่านได้ รวม `postUpdate.plugins.warnings` เมื่อ Plugin ที่มีการจัดการต้องได้รับการซ่อมแซม รายละเอียดการใช้ทางเลือกสำรองของ Plugin ในช่องทาง beta และ `postUpdate.plugins.integrityDrifts` เมื่อตรวจพบความคลาดเคลื่อนของอาร์ติแฟกต์ Plugin npm ระหว่างการซิงค์หลังการอัปเดต                                                                 |
| `--timeout <seconds>`                            | ระยะหมดเวลาต่อขั้นตอน ค่าเริ่มต้นคือ `1800`                                                                                                                                                                                                                                                                                                            |
| `--yes`                                          | ข้ามข้อความแจ้งเพื่อยืนยัน (เช่น การยืนยันการดาวน์เกรด)                                                                                                                                                                                                                                                                              |
| `--acknowledge-clawhub-risk`                     | อนุญาตให้การซิงค์ Plugin หลังการอัปเดตดำเนินต่อไปแม้มีคำเตือนด้านความน่าเชื่อถือจาก ClawHub ชุมชน โดยไม่ต้องแสดงข้อความแจ้งแบบโต้ตอบ หากไม่มีตัวเลือกนี้ รุ่นจากชุมชนที่มีความเสี่ยงจะถูกข้ามและคงไว้โดยไม่เปลี่ยนแปลงเมื่อ OpenClaw ไม่สามารถแสดงข้อความแจ้งได้ แพ็กเกจ ClawHub อย่างเป็นทางการและแหล่งที่มาของ Plugin ที่รวมมาในชุดจะข้ามข้อความแจ้งนี้                                                     |

ไม่มีแฟล็ก `--verbose` ใช้ `--dry-run` เพื่อแสดงตัวอย่างการดำเนินการที่วางแผนไว้
ใช้ `--json` สำหรับผลลัพธ์ที่เครื่องอ่านได้ และใช้ `openclaw update status --json`
สำหรับข้อมูลช่องทาง/ความพร้อมใช้งานเท่านั้น ระดับความละเอียดของคอนโซล Gateway (`--verbose`) และ
ระดับบันทึกไฟล์ (`logging.level: "debug"`/`"trace"`) เป็นการตั้งค่าที่แยกจากกัน โปรดดู
[การบันทึกของ Gateway](/th/gateway/logging)

<Note>
ในโหมด Nix (`OPENCLAW_NIX_MODE=1`) การเรียกใช้ `openclaw update` ที่เปลี่ยนแปลงข้อมูลจะถูกปิดใช้งาน ให้อัปเดตแหล่งที่มา Nix หรืออินพุต flake สำหรับการติดตั้งนี้แทน สำหรับ nix-openclaw ให้ใช้ [การเริ่มต้นอย่างรวดเร็ว](https://github.com/openclaw/nix-openclaw#quick-start) แบบให้เอเจนต์ทำงานก่อน `openclaw update status` และ `openclaw update --dry-run` ยังคงเป็นแบบอ่านอย่างเดียว
</Note>

<Warning>
การดาวน์เกรดต้องได้รับการยืนยัน เนื่องจากเวอร์ชันเก่าอาจทำให้การกำหนดค่าเสียหาย
หากการติดตั้งได้ย้ายเซสชันไปยัง SQLite แล้ว ให้กู้คืนอาร์ติแฟกต์ทรานสคริปต์แบบเดิมที่เก็บถาวรไว้
ก่อนเริ่มใช้เวอร์ชันเก่าที่ใช้ไฟล์เป็นพื้นที่จัดเก็บ โปรดดู
[Doctor: การดาวน์เกรดหลังจากย้ายเซสชันไปยัง SQLite](/th/cli/doctor#downgrading-after-session-sqlite-migration)
</Warning>

## `update status`

แสดงช่องทางอัปเดตที่ใช้งานอยู่ แท็ก/สาขา/SHA ของ git (เฉพาะเช็กเอาต์ซอร์ส)
และความพร้อมใช้งานของการอัปเดต

```bash
openclaw update status
openclaw update status --json
openclaw update status --timeout 10
```

| แฟล็ก                  | ค่าเริ่มต้น | คำอธิบาย                         |
| --------------------- | ------- | ----------------------------------- |
| `--json`              | `false` | แสดง JSON สถานะที่เครื่องอ่านได้ |
| `--timeout <seconds>` | `3`     | ระยะหมดเวลาสำหรับการตรวจสอบ                 |

สำหรับการติดตั้งแพ็กเกจ extended-stable สถานะจะใช้ตัวเลือกสาธารณะ
และการตรวจสอบแพ็กเกจแบบระบุแน่นอนเช่นเดียวกับการอัปเดตในโฟร์กราวด์ โดยอาจรายงาน
`ahead of extended-stable` เมื่อเวอร์ชันที่ติดตั้งใหม่กว่า ความล้มเหลวใน JSON
จะรวม `registry.reason` (`selector_missing`, `selector_query_failed`,
`exact_package_mismatch` หรือ `unsupported_git_channel`)

## `update repair`

เรียกใช้การดำเนินการขั้นสุดท้ายของการอัปเดตอีกครั้ง หลังจากแพ็กเกจคอร์เปลี่ยนแล้วแต่
งานซ่อมแซมภายหลังไม่เสร็จสมบูรณ์ นี่คือเส้นทางการกู้คืนที่รองรับเมื่อ
`openclaw update` ติดตั้งแพ็กเกจคอร์ใหม่แล้ว แต่การซิงค์ Plugin หลังอัปเดตคอร์
ข้อมูลเมตาของ Plugin npm ที่มีการจัดการ การรีเฟรชรีจิสทรี หรือการซ่อมแซมโดย Doctor
ยังไม่เข้าสู่สถานะสอดคล้องกัน

```bash
openclaw update repair
openclaw update repair --channel beta
openclaw update repair --acknowledge-clawhub-risk
openclaw update repair --json
```

| แฟล็ก                                             | คำอธิบาย                                                                                                                                                                                                                                                         |
| ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--channel <stable\|extended-stable\|beta\|dev>` | บันทึกช่องทางอัปเดตคอร์ก่อนการซ่อมแซม สำหรับ extended-stable Plugin npm อย่างเป็นทางการที่มีสิทธิ์ซึ่งใช้เป้าหมายตามเจตนาแบบเปล่า/ค่าเริ่มต้นหรือ `latest` จะกำหนดเป้าหมายเป็นเวอร์ชันคอร์ที่ติดตั้งแบบระบุแน่นอน การซ่อมแซม extended-stable จะถูกปฏิเสธในเช็กเอาต์ Git โดยไม่เปลี่ยนแปลงการกำหนดค่า |
| `--json`                                         | แสดง JSON การดำเนินการขั้นสุดท้ายที่เครื่องอ่านได้                                                                                                                                                                                                                           |
| `--timeout <seconds>`                            | ระยะหมดเวลาสำหรับขั้นตอนการซ่อมแซม ค่าเริ่มต้นคือ `1800`                                                                                                                                                                                                                           |
| `--yes`                                          | ข้ามข้อความแจ้งเพื่อยืนยัน                                                                                                                                                                                                                                          |
| `--acknowledge-clawhub-risk`                     | มีลักษณะการทำงานเหมือนกับใน `openclaw update`                                                                                                                                                                                                                              |
| `--no-restart`                                   | ยอมรับเพื่อให้สอดคล้องกัน แต่การซ่อมแซมจะไม่รีสตาร์ต Gateway                                                                                                                                                                                                             |

`update repair` จะเรียกใช้ `openclaw doctor --fix` โหลดการกำหนดค่าที่ซ่อมแซมแล้วและ
ระเบียนการติดตั้งใหม่ ซิงค์ Plugin ที่ติดตามไว้สำหรับช่องทางอัปเดตที่ใช้งานอยู่ อัปเดต
การติดตั้ง Plugin npm ที่มีการจัดการ ซ่อมแซมเพย์โหลด Plugin ที่กำหนดค่าไว้แต่ขาดหาย
รีเฟรชรีจิสทรี Plugin และเขียนข้อมูลเมตาของระเบียนการติดตั้งที่เข้าสู่สถานะสอดคล้องกัน
คำสั่งนี้จะไม่ติดตั้งแพ็กเกจคอร์ใหม่และจะไม่รีสตาร์ต Gateway

## `update wizard`

ขั้นตอนแบบโต้ตอบสำหรับเลือกช่องทางอัปเดตและยืนยันว่าจะรีสตาร์ต
Gateway ภายหลังหรือไม่ (ค่าเริ่มต้นคือรีสตาร์ต) การเลือก `dev` โดยไม่มีเช็กเอาต์ git
จะแสดงตัวเลือกให้สร้างเช็กเอาต์

| แฟล็ก                  | ค่าเริ่มต้น | คำอธิบาย                   |
| --------------------- | ------- | ----------------------------- |
| `--timeout <seconds>` | `1800`  | ระยะหมดเวลาสำหรับแต่ละขั้นตอนการอัปเดต |

## การทำงาน

การสลับช่องทางอย่างชัดเจน (`--channel ...`) ยังทำให้วิธีการติดตั้ง
สอดคล้องกันด้วย:

- `dev` -> ตรวจสอบให้มีเช็กเอาต์ git (ค่าเริ่มต้นคือ `~/openclaw` หรือ
  `$OPENCLAW_HOME/openclaw` เมื่อตั้งค่า `OPENCLAW_HOME`; แทนที่ได้ด้วย
  `OPENCLAW_GIT_DIR`) อัปเดตเช็กเอาต์นั้น และติดตั้ง CLI แบบ global จาก
  เช็กเอาต์ดังกล่าว
- `stable` -> ติดตั้งจาก npm โดยใช้ `latest`
- `extended-stable` -> แก้ไขตัวเลือก npm สาธารณะ `extended-stable`
  ตรวจสอบแพ็กเกจที่เลือกแบบระบุแน่นอน และติดตั้งเวอร์ชันดังกล่าวโดยตรง
  โดยจะไม่ใช้ตัวเลือกอื่นเป็นทางเลือกสำรองและจะถูกปฏิเสธสำหรับเช็กเอาต์ Git
- `beta` -> ให้ความสำคัญกับ dist-tag `beta` ของ npm และใช้ `latest` เป็นทางเลือกสำรองเมื่อไม่มี beta
  หรือ beta เก่ากว่ารุ่น stable ปัจจุบัน

### การส่งต่อเพื่อรีสตาร์ต

ตัวอัปเดตอัตโนมัติของคอร์ Gateway (เมื่อเปิดใช้งานผ่านการกำหนดค่า) จะเรียกใช้เส้นทาง
การอัปเดตของ CLI ภายนอกตัวจัดการคำขอ Gateway ที่กำลังทำงาน การอัปเดตผ่านตัวจัดการแพ็กเกจ
`update.run` ของระนาบควบคุมและการอัปเดตเช็กเอาต์ git ที่มีการกำกับดูแลจะใช้
การส่งต่อไปยังบริการที่มีการจัดการแบบเดียวกัน แทนการแทนที่โครงสร้างแพ็กเกจหรือ
สร้าง `dist/` ใหม่ภายในกระบวนการ Gateway ที่กำลังทำงาน กล่าวคือ Gateway จะเริ่ม
ตัวช่วยแบบแยกออกจากกระบวนการแล้วออก จากนั้นตัวช่วยดังกล่าวจะเรียกใช้ `openclaw update --yes --json`
จากภายนอกโครงสร้างกระบวนการ Gateway หากการส่งต่อไม่พร้อมใช้งาน
`update.run` จะส่งคืนการตอบกลับแบบมีโครงสร้างพร้อมคำสั่งเชลล์ที่ปลอดภัยสำหรับเรียกใช้
ด้วยตนเอง

การเลือก extended-stable ที่จัดเก็บไว้จะได้รับคำแนะนำแบบอ่านอย่างเดียวเมื่อเริ่มต้นระบบและทุก 24 ชั่วโมงเกี่ยวกับการอัปเดต เมื่อเปิดใช้งาน `update.checkOnStart` การตรวจสอบเหล่านี้จะไม่นำการอัปเดตมาใช้
ไม่เริ่มการส่งต่องาน ไม่รีสตาร์ต Gateway ไม่ใช้ระยะหน่วง/ความคลาดเคลื่อนแบบ stable และไม่ใช้
รอบการสำรวจแบบ beta การอัปเดตแบบ foreground ที่ระบุชัดเจน การอัปเดตแบบ foreground เปล่าที่มี
`update.channel: "extended-stable"` จัดเก็บไว้ สถานะแบบตามคำขอ และการส่งต่องานของ
Gateway ที่ได้รับการจัดการสำหรับรายการเหล่านี้ยังคงรองรับ

เมื่อติดตั้งบริการ Gateway ที่ได้รับการจัดการภายในเครื่องและเปิดใช้งานการรีสตาร์ต
การอัปเดตผ่านตัวจัดการแพ็กเกจและ git checkout จะหยุดบริการที่กำลังทำงานก่อน
แทนที่โครงสร้างแพ็กเกจหรือแก้ไข checkout/เอาต์พุตการบิลด์ จากนั้นตัวอัปเดต
จะรีเฟรชข้อมูลเมตาของบริการ รีสตาร์ตบริการ และตรวจสอบ
Gateway ที่รีสตาร์ตแล้วก่อนรายงาน `Gateway: restarted and verified.`
นอกจากนี้ การอัปเดตผ่านตัวจัดการแพ็กเกจยังตรวจสอบว่า Gateway ที่รีสตาร์ตรายงาน
เวอร์ชันแพ็กเกจที่คาดไว้ ส่วนการอัปเดต git checkout จะตรวจสอบสถานะความพร้อมใช้งานของ gateway และ
ความพร้อมของบริการหลังการบิลด์ใหม่

โดยปกติการอัปเดตผ่านตัวจัดการแพ็กเกจจะยังคงใช้ไบนารี Node ที่บันทึกไว้ใน
บริการที่ได้รับการจัดการ หาก Node นั้นไม่สามารถรันรุ่นเป้าหมายได้ แต่
Node ของ CLI ปัจจุบันทำได้ และพิสูจน์แล้วว่าบริการเป็นของแพ็กเกจที่กำลังอัปเดต
การอัปเดตที่เปิดใช้งานการรีสตาร์ตจะใช้ Node ปัจจุบันในการดำเนินการขั้นสุดท้าย และเขียน
ข้อมูลเมตาของบริการใหม่ให้ใช้รันไทม์นั้น `--no-restart` ไม่สามารถซ่อมแซมข้อมูลเมตา
ของบริการได้ ดังนั้นความไม่ตรงกันของรันไทม์แบบเดียวกันจะทำให้หยุดก่อนแก้ไขแพ็กเกจ

บน macOS การตรวจสอบหลังอัปเดตยังตรวจสอบว่า LaunchAgent
โหลด/ทำงานอยู่สำหรับโปรไฟล์ที่ใช้งาน และพอร์ต loopback ที่กำหนดค่าไว้
พร้อมใช้งาน หากติดตั้ง plist แล้ว แต่ launchd ไม่ได้ควบคุมดูแล OpenClaw
จะบูตสแตรป LaunchAgent ใหม่โดยอัตโนมัติ และเรียกใช้การตรวจสอบสถานะความพร้อมใช้งาน/เวอร์ชัน/
ความพร้อมของช่องทางอีกครั้ง (การบูตสแตรปใหม่จะโหลดงาน `RunAtLoad` โดยตรง
ดังนั้นการกู้คืนจึงไม่ `kickstart -k` Gateway ที่เพิ่งสร้างทันที) หาก
Gateway ยังไม่พร้อมใช้งาน คำสั่งจะออกด้วยรหัสที่ไม่ใช่ศูนย์ และ
พิมพ์พาธบันทึกการรีสตาร์ต พร้อมคำแนะนำสำหรับการรีสตาร์ต การติดตั้งใหม่ และการย้อนกลับ
แพ็กเกจ

หากไม่สามารถรีสตาร์ตได้ คำสั่งจะพิมพ์ `Gateway: restart skipped (...)` หรือ
`Gateway: restart failed: ...` พร้อมคำแนะนำให้ดำเนินการ `openclaw gateway restart` ด้วยตนเอง
เมื่อใช้ `--no-restart` การแทนที่แพ็กเกจหรือการบิลด์ git ใหม่จะยังคงทำงาน แต่
บริการที่ได้รับการจัดการจะไม่ถูกหยุดหรือรีสตาร์ต ดังนั้น Gateway ที่กำลังทำงานจะยังใช้
โค้ดเก่าจนกว่าจะรีสตาร์ตด้วยตนเอง

### รูปแบบการตอบกลับของระนาบควบคุม

เมื่อ `update.run` ทำงานผ่านระนาบควบคุมของ Gateway ในการติดตั้งผ่านตัวจัดการแพ็กเกจ
หรือ git checkout ที่มีการควบคุมดูแล ตัวจัดการจะรายงานการเริ่มต้นการส่งต่องาน
แยกจากการอัปเดตของ CLI ที่ดำเนินต่อหลังจาก Gateway ออก:

- `ok: true`, `result.status: "skipped"`,
  `result.reason: "managed-service-handoff-started"` และ
  `handoff.status: "started"`: Gateway ได้สร้างการส่งต่องานของบริการที่ได้รับการจัดการ
  และกำหนดเวลาการรีสตาร์ตของตัวเอง เพื่อให้ตัวช่วยที่แยกออกมาสามารถเรียกใช้
  `openclaw update --yes --json` ภายนอกโพรเซสบริการที่กำลังทำงาน
- `ok: false`, `result.reason: "managed-service-handoff-unavailable"` และ
  `handoff.status: "unavailable"`: OpenClaw ไม่พบขอบเขตบริการที่ควบคุมดูแล
  และข้อมูลประจำตัวบริการที่คงทนสำหรับการส่งต่องานอย่างปลอดภัย (ตัวอย่างเช่น
  การส่งต่องานของ systemd ต้องใช้ข้อมูลประจำตัวหน่วย `OPENCLAW_SYSTEMD_UNIT`
  ไม่ใช่เพียงตัวบ่งชี้โพรเซส systemd จากสภาพแวดล้อม) การตอบกลับประกอบด้วย
  `handoff.command` ซึ่งเป็นคำสั่งเชลล์ที่ต้องเรียกใช้จากภายนอก Gateway
- `ok: false`, `result.reason: "managed-service-handoff-failed"`: Gateway
  พยายามสร้างการส่งต่องาน แต่ไม่สามารถสร้างโพรเซสตัวช่วยที่แยกออกมาได้

เพย์โหลด `sentinel` จะถูกเขียนก่อน Gateway ออก และการส่งต่องานของ CLI
จะอัปเดตตัวบ่งชี้การรีสตาร์ตเดียวกันหลังจากการตรวจสอบสถานะความพร้อมใช้งานของบริการที่ได้รับการจัดการ
หลังรีสตาร์ตเสร็จสมบูรณ์ ระหว่างการส่งต่องาน ตัวบ่งชี้สามารถมี
`stats.reason: "restart-health-pending"` โดยไม่มีการดำเนินการต่อเมื่อสำเร็จ
Gateway ที่รีสตาร์ตจะสำรวจตัวบ่งชี้นี้ และเรียกการดำเนินการต่อเมื่อ CLI
ตรวจสอบสถานะความพร้อมใช้งานของบริการแล้ว และเขียนตัวบ่งชี้ใหม่ด้วยผลลัพธ์ `ok` ขั้นสุดท้ายเท่านั้น
`openclaw status` และ `openclaw status --all` แสดงแถว `Update restart`
ขณะที่ตัวบ่งชี้นั้นกำลังรอดำเนินการหรือล้มเหลว และ `update.status` จะรีเฟรชและ
ส่งคืนตัวบ่งชี้ล่าสุด

## ขั้นตอนของ Git checkout

### การเลือกช่องทาง

- `stable`: checkout แท็กล่าสุดที่ไม่ใช่ beta จากนั้นบิลด์และเรียกใช้ doctor
- `beta`: เลือกใช้แท็ก `-beta` ล่าสุด โดยถอยกลับไปใช้แท็ก stable ล่าสุด
  เมื่อไม่มี beta หรือ beta เก่ากว่า
- `dev`: checkout `main` จากนั้น fetch และ rebase
- `extended-stable`: ไม่รองรับสำหรับ Git checkout และจะไม่มีการแก้ไข
  checkout

### ขั้นตอนการอัปเดต

<Steps>
  <Step title="ตรวจสอบว่า worktree สะอาด">
    ต้องไม่มีการเปลี่ยนแปลงที่ยังไม่ได้ commit
  </Step>
  <Step title="สลับช่องทาง">
    สลับไปยังช่องทางที่เลือก (แท็กหรือสาขา)
  </Step>
  <Step title="ดึงข้อมูลจาก upstream">
    สำหรับ Dev เท่านั้น
  </Step>
  <Step title="บิลด์ตรวจสอบล่วงหน้า (เฉพาะ dev)">
    เรียกใช้การบิลด์ TypeScript ใน worktree ชั่วคราว หากปลายสาขาล้มเหลว ระบบจะย้อนกลับได้สูงสุด 10 commit เพื่อค้นหา commit ล่าสุดที่บิลด์ได้ ตั้งค่า `OPENCLAW_UPDATE_PREFLIGHT_LINT=1` เพื่อเรียกใช้ lint ระหว่างการตรวจสอบล่วงหน้านี้ด้วย โดย lint จะทำงานในโหมดอนุกรมแบบจำกัด เนื่องจากโฮสต์ที่ผู้ใช้ใช้ในการอัปเดตมักมีขนาดเล็กกว่ารันเนอร์ CI
  </Step>
  <Step title="Rebase">
    rebase ไปยัง commit ที่เลือก (เฉพาะ dev)
  </Step>
  <Step title="ติดตั้งการขึ้นต่อกัน">
    ใช้ตัวจัดการแพ็กเกจของ repo สำหรับ pnpm checkout ตัวอัปเดตจะบูตสแตรป `pnpm` ตามคำขอ (ผ่าน `corepack` ก่อน จากนั้นใช้ `npm install pnpm@11` ชั่วคราวเป็นทางเลือกสำรอง) แทนการเรียกใช้ `npm run build` ภายใน pnpm workspace หากการบูตสแตรป pnpm ยังคงล้มเหลว ตัวอัปเดตจะหยุดก่อนกำหนดพร้อมข้อผิดพลาดเฉพาะตัวจัดการแพ็กเกจ แทนที่จะลองใช้ `npm run build` ใน checkout
  </Step>
  <Step title="บิลด์ Control UI">
    บิลด์ gateway และ Control UI
  </Step>
  <Step title="เรียกใช้ doctor">
    `openclaw doctor` ทำงานเป็นการตรวจสอบการอัปเดตอย่างปลอดภัยขั้นสุดท้าย
  </Step>
  <Step title="ซิงค์ plugins">
    ซิงค์ plugins ไปยังช่องทางที่ใช้งาน Dev ใช้ plugins ที่รวมมาให้ ส่วน stable และ beta ใช้ npm อัปเดตการติดตั้ง plugin ที่ติดตามไว้
  </Step>
</Steps>

### รายละเอียดการซิงค์ Plugin

ในช่องทาง beta การติดตั้ง plugin จาก npm และ ClawHub ที่ติดตามไว้และใช้สาย
default/latest จะลองใช้รุ่น `@beta` ของ plugin ก่อน หาก plugin ไม่มี
รุ่น beta OpenClaw จะถอยกลับไปใช้ข้อกำหนด default/latest ที่บันทึกไว้ และ
รายงานคำเตือน สำหรับ plugin จาก npm OpenClaw จะถอยกลับเช่นกันเมื่อมีแพ็กเกจ
beta แต่ไม่ผ่านการตรวจสอบการติดตั้ง คำเตือนจากการถอยกลับเหล่านี้จะไม่ทำให้
การอัปเดตแกนหลักล้มเหลว เวอร์ชันที่ระบุแน่นอนและแท็กที่ระบุชัดเจนจะไม่ถูกเขียนใหม่

<Warning>
หากการอัปเดต plugin จาก npm ที่ปักหมุดเวอร์ชันแน่นอนแก้ไขไปยังอาร์ติแฟกต์ที่มีค่าความสมบูรณ์แตกต่างจากบันทึกการติดตั้งที่จัดเก็บไว้ `openclaw update` จะยกเลิกการอัปเดตอาร์ติแฟกต์ของ plugin นั้นแทนการติดตั้ง ให้ติดตั้งใหม่หรืออัปเดต plugin อย่างชัดเจนเฉพาะหลังจากตรวจสอบแล้วว่าเชื่อถืออาร์ติแฟกต์ใหม่
</Warning>

<Note>
ความล้มเหลวในการซิงค์ plugin หลังอัปเดตที่จำกัดอยู่เฉพาะ plugin ที่ได้รับการจัดการและเส้นทางการซิงค์สามารถหลีกเลี่ยงได้ (ตัวอย่างเช่น รีจิสทรี npm ที่เข้าถึงไม่ได้สำหรับ plugin ที่ไม่จำเป็น) จะถูกรายงานเป็นคำเตือนหลังจากการอัปเดตแกนหลักสำเร็จ ผลลัพธ์ JSON จะเก็บ `status: "ok"` ของการอัปเดตระดับบนสุดไว้ และรายงาน `postUpdate.plugins.status: "warning"` พร้อมคำแนะนำ `openclaw update repair` และ `openclaw plugins inspect <id> --runtime --json` ข้อยกเว้นที่ไม่คาดคิดจากตัวอัปเดตหรือการซิงค์ยังคงทำให้ผลลัพธ์การอัปเดตล้มเหลว แก้ไขข้อผิดพลาดในการติดตั้งหรืออัปเดต plugin แล้วเรียกใช้ `openclaw update repair` อีกครั้ง เมื่อการอัปเดตที่ล้มเหลวทำให้ plugin ที่ได้รับการจัดการใช้งานไม่ได้ OpenClaw จะปิดใช้งานรายการรันไทม์ของ plugin และรีเซ็ตสล็อตที่ใช้งาน โดยไม่เปลี่ยนนโยบาย `plugins.allow` หรือ `plugins.deny` ที่ผู้ปฏิบัติงานกำหนดไว้

หลังจากขั้นตอนการซิงค์แต่ละ plugin แล้ว `openclaw update` จะเรียกใช้รอบ **การบรรจบกันหลังแกนหลัก** ที่จำเป็นก่อน gateway รีสตาร์ต โดยจะซ่อมแซมเพย์โหลด plugin ที่กำหนดค่าไว้แต่สูญหาย ตรวจสอบบันทึกการติดตั้งที่ติดตามแต่ละรายการซึ่ง _ใช้งานอยู่_ บนดิสก์ และตรวจสอบแบบสแตติกว่า `package.json` สามารถแยกวิเคราะห์ได้ (และ `main` ใด ๆ ที่ประกาศไว้อย่างชัดเจนมีอยู่จริง) ความล้มเหลวจากรอบนี้และสแนปช็อตการกำหนดค่าที่ไม่ถูกต้องจะส่งคืน `postUpdate.plugins.status: "error"` และเปลี่ยน `status` ของการอัปเดตระดับบนสุดเป็น `"error"` ทำให้ `openclaw update` ออกด้วยรหัสที่ไม่ใช่ศูนย์ และ gateway จะ _ไม่_ รีสตาร์ตพร้อมชุด plugin ที่ยังไม่ได้รับการตรวจสอบ ข้อผิดพลาดประกอบด้วยบรรทัด `postUpdate.plugins.warnings[].guidance` แบบมีโครงสร้างที่ชี้ไปยัง `openclaw update repair` และ `openclaw plugins inspect <id> --runtime --json` รายการ plugin ที่ปิดใช้งานและบันทึกที่ไม่ได้เชื่อมโยงกับแหล่งที่เชื่อถือได้ซึ่งเป็นเป้าหมายการซิงค์อย่างเป็นทางการจะถูกข้ามในขั้นตอนนี้ (สอดคล้องกับนโยบาย `skipDisabledPlugins` ที่ใช้โดยการตรวจสอบเพย์โหลดที่สูญหาย) ดังนั้นบันทึก plugin ที่ปิดใช้งานและล้าสมัยจะไม่สามารถขัดขวางการอัปเดตที่ถูกต้องในด้านอื่น

เมื่อ Gateway ที่อัปเดตแล้วเริ่มทำงาน การโหลด plugin จะเป็นแบบตรวจสอบเท่านั้น การเริ่มต้นระบบจะไม่เรียกใช้ตัวจัดการแพ็กเกจหรือแก้ไขโครงสร้างการขึ้นต่อกัน การรีสตาร์ต `update.run` ผ่านตัวจัดการแพ็กเกจจะถูกส่งต่อให้เส้นทางบริการที่ได้รับการจัดการของ CLI เพื่อให้การสลับแพ็กเกจเกิดขึ้นภายนอกโพรเซส Gateway เดิม และให้การตรวจสอบสถานะความพร้อมใช้งานของบริการเป็นตัวตัดสินว่าสามารถรายงานว่าการอัปเดตเสร็จสมบูรณ์ได้หรือไม่
</Note>

หลังจากการอัปเดตแกนหลัก extended-stable สำเร็จ ความสมบูรณ์และ
การบรรจบกันของ plugin หลังแกนหลักจะกำหนดเป้าหมายไปยัง plugin npm อย่างเป็นทางการที่เข้าเกณฑ์ ณ เวอร์ชันแกนหลัก
ที่ติดตั้งไว้อย่างแน่นอน สำหรับเจตนา default/`latest` OpenClaw จะไม่ค้นหา
`@extended-stable` ของ plugin หรือถอยกลับไปใช้ `latest` ของ npm แต่จะอนุมานเวอร์ชันแพ็กเกจ
จากแกนหลักที่ติดตั้งไว้ การปักหมุดเวอร์ชันอย่างชัดเจน แท็กที่ระบุชัดเจนซึ่งไม่ใช่ `latest`
แพ็กเกจของบุคคลที่สาม และแหล่งที่ไม่ใช่ npm จะคงเจตนาที่มีอยู่ไว้

สำหรับการติดตั้งผ่านตัวจัดการแพ็กเกจ `openclaw update` จะแก้ไขเวอร์ชันแพ็กเกจ
เป้าหมายก่อนเรียกใช้ตัวจัดการแพ็กเกจ การติดตั้ง npm แบบ global ใช้การติดตั้งแบบ staged:
OpenClaw ติดตั้งแพ็กเกจใหม่ลงใน prefix ชั่วคราวของ npm
ให้แพ็กเกจตัวเลือกตรวจสอบเวอร์ชัน Node ของโฮสต์ระหว่าง `preinstall`
และตรวจสอบรายการ `dist` ที่บรรจุในแพ็กเกจที่นั่น ตัวป้องกันความสมบูรณ์
ของแพ็กเกจจะอยู่นอกรายการนั้นจนกว่า `preinstall` จะสำเร็จ เพื่อให้ตัวจัดการแพ็กเกจ
ที่ข้ามสคริปต์วงจรชีวิตหยุดก่อนเปิดใช้งานด้วย บน npm 12 และใหม่กว่า
ตัวอัปเดตจะอนุมัติเฉพาะวงจรชีวิตของ OpenClaw ตัวเลือก ส่วนสคริปต์ของ
การขึ้นต่อกันแบบส่งผ่านจะยังคงถูกบล็อก จากนั้น OpenClaw จะสลับโครงสร้างแพ็กเกจที่สะอาด
เข้าไปใน prefix แบบ global จริง หากการตรวจสอบล้มเหลว doctor หลังอัปเดต การซิงค์ plugin
และงานรีสตาร์ตจะไม่ทำงานจากโครงสร้างที่น่าสงสัย แม้เมื่อ
เวอร์ชันที่ติดตั้งตรงกับเป้าหมายแล้ว คำสั่งจะรีเฟรช
การติดตั้งแพ็กเกจแบบ global จากนั้นเรียกใช้การซิงค์ plugin การรีเฟรชความสมบูรณ์
ของคำสั่งแกนหลัก และงานรีสตาร์ต ซึ่งช่วยให้องค์ประกอบข้างเคียงที่บรรจุในแพ็กเกจและบันทึก
plugin ที่ช่องทางเป็นเจ้าของสอดคล้องกับบิลด์ OpenClaw ที่ติดตั้งไว้ ขณะที่ปล่อยให้การบิลด์
ความสมบูรณ์ของคำสั่ง plugin แบบเต็มเป็นหน้าที่ของการเรียกใช้
`openclaw completion --write-state` อย่างชัดเจน

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

- `openclaw doctor` (เสนอให้เรียกใช้การอัปเดตก่อนสำหรับ git checkout)
- [ช่องทางการพัฒนา](/th/install/development-channels)
- [การอัปเดต](/th/install/updating)
- [เอกสารอ้างอิง CLI](/th/cli)
