GitHub CLI 2.103.0 เปิดใช้โทเคนหมดอายุเอง ลดเวลาที่สิทธิ์หลุดถูกใช้ต่อ

GitHub CLI รุ่น 2.103.0 เปิดให้เลือกใช้โทเคนเข้าถึงที่หมดอายุภายในไม่กี่ชั่วโมง พร้อมต่ออายุอัตโนมัติ โดยยังอยู่ในสถานะ public preview หรือพรีวิวที่เปิดให้คนทั่วไปทดลอง ตามประกาศวันที่ 21 ตุลาคม 2026 ของ GitHub ครับ ประเด็นสำคัญคือ ถ้าโทเคนเข้าถึงหลุดออกไป มันจะใช้ไม่ได้เมื่อหมดอายุ แทนที่จะคงอยู่ได้เรื่อย ๆ แบบโทเคนไม่หมดอายุ (GitHub Changelog)

สำหรับคนที่ต้องดูแลเว็บร้านค้า งานส่งลูกค้า หรือระบบที่ทีมใช้ทุกวัน ผมคิดว่าเรื่องนี้เกี่ยวกับทั้งความเสี่ยงและเวลางาน เพราะการเปลี่ยนวิธียืนยันตัวตนอาจทำให้สคริปต์เดิมสะดุดได้ GitHub เตือนไว้ตรง ๆ ว่าสคริปต์ที่อ่านโทเคนครั้งเดียวแล้วเก็บไปใช้ต่อ จะถือโทเคนที่หมดอายุในที่สุด ดังนั้นข่าวนี้มีทั้งเหตุผลให้อัปเกรดและการบ้านที่ต้องตรวจ ก่อนกดเปิดใช้ทั้งทีม (GitHub Changelog)

สรุป 30 วินาที: เกิดอะไรขึ้น

GitHub CLI คือเครื่องมือของ GitHub ที่ใช้งานด้วยการพิมพ์คำสั่ง เรียกสั้น ๆ ว่า gh รุ่น 2.103.0 เพิ่มการลงชื่อเข้าใช้ด้วย OAuth credentials แบบหมดอายุและต่ออายุได้อัตโนมัติ โดย credentials ในที่นี้หมายถึงข้อมูลที่ใช้ยืนยันสิทธิ์เข้าถึง ส่วน OAuth คือรูปแบบการให้โปรแกรมได้รับสิทธิ์จากบริการเพื่อทำงานแทนผู้ใช้ (GitHub Releases)

การเปิดใช้สำหรับการลงชื่อเข้าใช้ครั้งหนึ่งทำผ่าน gh auth login --expiring หากต้องการให้การลงชื่อเข้าใช้ครั้งต่อ ๆ ไปเลือกแบบนี้เป็นหลัก ให้ตั้งค่า gh config set expiring_credentials enabled ทั้งสองแบบเป็นการเลือกใช้เองในตอนนี้ ไม่ได้เปลี่ยนการลงชื่อเข้าใช้เดิมให้ทุกคนทันที และโทเคนที่ผู้ใช้ป้อนเองยังทำงานแบบเดิม (GitHub Changelog)

คำสั่ง gh auth status ใช้ดูได้ว่าข้อมูลยืนยันสิทธิ์รองรับการต่ออายุหรือไม่ และโทเคนเข้าถึงปัจจุบันจะหมดอายุเมื่อไร ทั้งคำสั่งนี้และ gh auth token จะต่ออายุโทเคนให้เมื่อจำเป็น แต่ค่าที่ถูกพิมพ์ออกมาจาก gh auth token ไม่ควรถูกเก็บค้างไว้ใช้ยาว ๆ (GitHub Releases)

ฟีเจอร์นี้พร้อมใช้บน github.com และ GHE.com ส่วนโฮสต์หรือระบบปลายทางที่ไม่ออกโทเคนชนิดนี้ gh จะกลับไปใช้โทเคนปกติที่ไม่หมดอายุ การใส่ตัวเลือกจึงยังไม่ใช่หลักฐานว่าได้โทเคนแบบหมดอายุแล้ว ต้องดูสถานะที่ได้รับจริงด้วย (GitHub Releases, คู่มือ GitHub CLI)

ทำไมเรื่องนี้เกี่ยวกับคุณ

ถ้าคุณเขียนโปรแกรมเอง จุดที่ต้องสนใจคือโทเคนที่เคยขอมาแล้วใช้ได้นาน อาจเปลี่ยนเป็นโทเคนที่ต้องขอค่าปัจจุบันใหม่เมื่อจำเป็น หากใช้ผ่าน gh ตามเส้นทางที่รองรับ เครื่องมือจะจัดการการต่ออายุให้ แต่ถ้าคัดลอกค่าไปใส่เครื่องมืออื่น การดูแลอายุของค่านั้นจะกลายเป็นเรื่องที่ต้องตรวจเพิ่ม GitHub ระบุทั้งสคริปต์และส่วนขยายว่าอาจเจอปัญหานี้ได้ (GitHub Changelog)

ถ้าคุณเป็นเจ้าของกิจการหรือหัวหน้าทีม ผมแนะนำให้คุยกับคนดูแลระบบด้วยคำถามที่จับต้องได้ เช่น งานอัตโนมัติของเราขอสิทธิ์ตอนไหน เก็บไว้ที่ไหน และเรียกค่าที่เก็บไว้ซ้ำนานแค่ไหน เหตุผลที่ต้องถามคือ GitHub เตือนว่างานที่ต้องพึ่งโทเคนอายุยาวควรชะลอการเปิดใช้สำหรับงานนั้นไว้ก่อน ไม่ได้แนะนำให้เปิดทุกงานพร้อมกัน (GitHub Changelog)

ส่วนคนทำงานสำนักงาน นักเรียน หรือผู้ปกครองที่ไม่ได้ใช้ gh เอง ผมมองว่าประโยชน์ของข่าวนี้คือเข้าใจเวลาทีมไอทีขอทดสอบการลงชื่อเข้าใช้ใหม่ มากกว่าต้องไปตั้งค่าตามทุกคน เพราะ GitHub ระบุว่าหากไม่เลือกใช้ผ่านตัวเลือกหรือการตั้งค่า พฤติกรรมเดิมจะไม่เปลี่ยน และการลงชื่อเข้าใช้ที่มีอยู่ยังทำงานต่อไป (GitHub Changelog)

ทำงานยังไง

ข้อมูลยืนยันสิทธิ์ชุดใหม่มีสองส่วน ส่วนแรกคือ access token หรือโทเคนเข้าถึง เป็นค่าที่โปรแกรมนำไปใช้เพื่อทำงานด้วยสิทธิ์ที่ได้รับ ส่วนที่สองคือ refresh token หรือโทเคนสำหรับขอสิทธิ์ชุดใหม่ เมื่อจำเป็นต้องต่ออายุ gh จะใช้ส่วนที่สองขอโทเคนเข้าถึงใหม่ โดยผู้ใช้ยังทำงานต่อได้โดยไม่ต้องลงชื่อเข้าใช้ใหม่ทุกครั้ง (GitHub Changelog)

ลองนึกถึง บัตรผ่านตึกแบบรายวันกับกุญแจบ้านถาวร ครับ บัตรรายวันมีเวลาหมดอายุ ต่อให้ทำหล่น คนที่เก็บได้ก็ใช้บัตรใบนั้นต่อไม่ได้หลังหมดเวลา ส่วนกุญแจถาวรไม่มีเวลาตัดสิทธิ์ในตัว ในภาพเปรียบเทียบนี้ gh ช่วยจัดการรับบัตรใบใหม่ให้เจ้าของตามสิทธิ์ที่ยังมีอยู่ ภาพนี้ใช้อธิบายความต่างของอายุโทเคน ไม่ได้หมายความว่าโทเคนของ GitHub มีอายุหนึ่งวัน เพราะแหล่งข่าวบอกเพียงว่าหมดอายุภายในไม่กี่ชั่วโมง (GitHub Changelog)

ส่วน refresh token ก็ไม่ได้อยู่ค่าเดิมตลอด เอกสารออกแบบอธิบายว่าเมื่อใช้ต่ออายุแล้ว เซิร์ฟเวอร์จะออก refresh token ใหม่และทำให้ค่าเดิมใช้ไม่ได้ จึงเหลือค่าล่าสุดเป็นตัวที่ยังใช้ได้ การหมุนเปลี่ยนค่านี้เป็นเหตุผลที่ต้องปล่อยให้ gh ดูแลข้อมูลชุดปัจจุบันอย่างเป็นระบบ แทนการคัดลอกค่าแยกไปเก็บหลายแห่งเอง (GitHub design issue)

เอกสารออกแบบยังอธิบายว่าระบบมีการจัดลำดับการต่ออายุ เพื่อป้องกันหลายโปรเซสหรือหลายชุดคำสั่งที่ทำงานพร้อมกันหยิบ refresh token เดียวกันไปใช้ชนกัน รายละเอียดนี้ช่วยให้เข้าใจว่าการต่ออายุอัตโนมัติมีงานเบื้องหลังมากกว่าการเปลี่ยนตัวเลขวันหมดอายุ อย่างไรก็ตาม เอกสารดังกล่าวเป็นบันทึกช่วงออกแบบ จึงควรใช้ประกอบความเข้าใจ และยึดคำสั่งจากประกาศรุ่นที่เผยแพร่แล้วเป็นหลัก (GitHub design issue, GitHub Releases)

ข้อจำกัดสำคัญคือ --expiring เป็นการขอให้เลือกโทเคนแบบหมดอายุ ผลจริงยังขึ้นกับการรองรับของโฮสต์และการตั้งค่าของแอป OAuth หากโฮสต์ไม่รองรับ จะได้โทเคนไม่หมดอายุแทน และคู่มือยังระบุด้วยว่าโฮสต์ที่ตั้งค่าไว้รองรับอาจออกโทเคนหมดอายุให้แม้ไม่ได้ใส่ตัวเลือกนี้ จึงควรอ่านสถานะจริงหลังลงชื่อเข้าใช้ทุกครั้งที่กำลังทดสอบพฤติกรรมนี้ (คู่มือ GitHub CLI)

จุดสังเกต: ต่ออายุให้คำสั่งได้ แต่ค่าที่คัดลอกไว้ไม่เปลี่ยนตาม

จุดที่ผมอยากวงไว้คือความต่างระหว่าง “เรียก gh ตอนต้องใช้” กับ “เก็บค่าจาก gh ไว้ตั้งแต่เริ่มงาน” ทั้ง gh auth status และ gh auth token ต่ออายุโทเคนเข้าถึงเมื่อจำเป็น แต่สคริปต์ที่เก็บผลลัพธ์ไว้แล้วเอาค่าเดิมกลับมาใช้ จะเจอโทเคนหมดอายุในที่สุด การอัปเกรดโปรแกรมจึงไม่ทำให้สำเนาที่เก็บอยู่ในสคริปต์สดใหม่ตามไปด้วย (GitHub Releases)

สำหรับคนใช้ CI ซึ่งหมายถึงระบบที่รันงานพัฒนาและตรวจสอบโค้ดอัตโนมัติ ผมแนะนำให้ตรวจเป็นพิเศษว่ามีงานไหนอ่าน gh auth token เพียงครั้งเดียวแล้วใช้ต่อหลายชั่วโมงหรือไม่ แนวทางจาก GitHub คืออ่านใหม่ทุกครั้งที่ต้องใช้โทเคนนอก gh เพื่อให้เครื่องมือมีโอกาสต่ออายุ ส่วนงานที่ยังต้องอาศัยค่าเดิมใช้ได้นาน ควรรอปรับงานให้พร้อมก่อนเปิดใช้ (GitHub Changelog)

อีกกรณีที่ต้องแยกให้ออกคือ GH_TOKEN และ GITHUB_TOKEN ซึ่งเป็นตัวแปรสภาพแวดล้อม หรือค่าที่ส่งให้โปรแกรมตอนทำงาน บันทึกรุ่นระบุว่าโทเคนที่ส่งเข้ามาทางสองตัวแปรนี้จะไม่ถูกต่ออายุ จึงไม่ควรสรุปว่างานอัตโนมัติทุกงานได้ความสามารถใหม่นี้ทันทีเพียงเพราะติดตั้ง gh รุ่นใหม่แล้ว (GitHub Releases)

เรื่องเงิน / ผลกระทบ

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

สำหรับเรื่องข้อมูลลับรั่วที่เป็นมุมกังวลในสัปดาห์นี้ บทความนี้ไม่มีหลักฐานเหตุการณ์เฉพาะจากแหล่งที่ให้มา จึงไม่ผูกฟีเจอร์ใหม่กับบริษัทหรือเหตุการณ์ใด ข้อที่ยืนยันได้คือ GitHub อธิบายการหมดอายุว่าเป็นวิธีลดเวลาที่ access token ซึ่งหลุดออกไปยังใช้การได้ ไม่ได้ให้ตัวเลขประเมินความเสียหายที่ป้องกันได้ (GitHub Changelog)

ด้านเวลางาน ผมประเมินว่าต้นทุนที่ควรเตรียมคือเวลาทดลองและแก้สคริปต์ มากกว่ามองแค่การอัปเดตเครื่องมือ เพราะคำเตือนที่ชัดเจนของ GitHub คือการเก็บโทเคนไว้ใช้ซ้ำอาจทำให้งานพังเมื่อมันหมดอายุ แหล่งข้อมูลไม่ได้ระบุค่าใช้จ่ายเพิ่มเติมของฟีเจอร์นี้ หรือจำนวนชั่วโมงที่แต่ละทีมต้องใช้ปรับระบบ จึงยังคำนวณความคุ้มค่าเป็นเงินบาทไม่ได้ (GitHub Changelog)

สำหรับ Git ซึ่งเป็นเครื่องมือจัดการประวัติการแก้ไขโค้ด หากเชื่อมต่อผ่าน HTTPS และต้องการใช้โทเคนหมดอายุ GitHub แนะนำให้ตั้ง gh เป็น credential helper หรือผู้ช่วยจัดหาข้อมูลยืนยันสิทธิ์ให้ Git ด้วย gh auth setup-git พร้อมใช้ Git 2.46 ขึ้นไป เพื่อให้โทเคนถูกทำเครื่องหมายไม่ให้เก็บค้างเกินอายุ รุ่นเก่ายังทำงานได้ แต่ gh จะแสดงคำแนะนำให้อัปเกรด (GitHub Changelog)

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

ยังไม่มีอายุโทเคนเป็นจำนวนชั่วโมงแน่นอนในข้อมูลชุดนี้ ประกาศและเอกสารออกแบบใช้คำว่าภายในไม่กี่ชั่วโมง จึงไม่ควรแปลงเป็นตัวเลขเฉพาะสำหรับวางตารางงาน ให้ดูเวลาหมดอายุของโทเคนปัจจุบันจาก gh auth status แทน (GitHub Changelog, GitHub design issue)

สถานะที่ยืนยันได้คือ public preview และเลือกเปิดเอง GitHub บอกว่ามีแผนให้โทเคนหมดอายุเป็นค่าเริ่มต้นสำหรับการลงชื่อเข้าใช้ใหม่ในรุ่นอนาคต แต่ไม่ได้ให้วันหรือหมายเลขรุ่นที่จะเปลี่ยน จึงยังบอกไม่ได้ว่าทีมต้องเตรียมเสร็จภายในวันไหน (GitHub Changelog)

ชื่อคำสั่งในเอกสารเก่ากับรุ่นเผยแพร่ต่างกัน Issue ออกแบบวันที่ 15 กันยายน 2026 ใช้ชื่อ --short-lived ขณะที่ประกาศวันที่ 21 ตุลาคมและบันทึกรุ่น 2.103.0 ใช้ --expiring รายการเปลี่ยนแปลงของรุ่นระบุว่ามีการเปลี่ยนชื่อนี้ด้วย จึงควรใช้ --expiring ตามเอกสารรุ่นที่ออกแล้ว ไม่คัดลอกคำสั่งทดลองจากบันทึกออกแบบ (GitHub design issue, GitHub Releases)

รายละเอียดการรองรับแต่ละโฮสต์มีระดับความชัดต่างกัน บันทึกรุ่นบอกว่าใช้ได้บน github.com และ GHE.com และโฮสต์ที่ไม่ออกโทเคนชนิดนี้จะกลับไปใช้แบบไม่หมดอายุ ส่วน Changelog ระบุเพิ่มว่า GitHub Enterprise Server หรือ GHES ซึ่งเป็นระบบ GitHub สำหรับติดตั้งใช้งานในองค์กร เริ่มออกโทเคนชนิดนี้ตั้งแต่ GHES 3.23 และรุ่นก่อนหน้านั้นจะกลับไปใช้แบบไม่หมดอายุ ข้อมูลนี้เป็นรายละเอียดเพิ่มเติม ไม่ใช่หลักฐานว่าองค์กรใดในไทยใช้ได้แล้ว (GitHub Releases, GitHub Changelog)

วันที่กำกับคู่มือควรอ่านอย่างระวัง ข้อมูลต้นทางให้วันที่คู่มือเป็น 1 มกราคม 2026 แต่เนื้อหาที่ได้รับมีตัวเลือก --expiring แล้ว จึงใช้เนื้อหาคู่มือยืนยันพฤติกรรมปัจจุบันตามที่ให้มา และใช้วันที่ 21 ตุลาคม 2026 จาก Changelog เป็นวันที่ประกาศข่าวนี้ ไม่ถือว่าวันที่กำกับคู่มือคือวันเปิดตัวฟีเจอร์ (คู่มือ GitHub CLI, GitHub Changelog)

แล้วเราควรทำอะไร

นักพัฒนาและคนใช้เครื่องส่วนตัว

1. อัปเกรดเป็น GitHub CLI 2.103.0 ก่อนทดลอง แล้วเริ่มจากเครื่องส่วนตัวหรืองานที่ตรวจผลได้ง่าย แนวทางเริ่มแบบจำกัดวงเป็นคำแนะนำของผม ส่วนรุ่นเริ่มรองรับยืนยันจากประกาศ GitHub (GitHub Changelog)
2. ทดลองลงชื่อเข้าใช้ด้วย gh auth login --expiring แล้วตรวจด้วย gh auth status ว่าได้รับโทเคนต่ออายุได้จริงหรือไม่ รวมถึงวันหมดอายุของค่าปัจจุบัน อย่าตัดสินจากการใส่ตัวเลือกสำเร็จเพียงอย่างเดียว เพราะผลขึ้นกับโฮสต์และการตั้งค่าแอป (คู่มือ GitHub CLI, GitHub Releases)
3. ถ้าใช้ Git ผ่าน HTTPS ให้ทำ gh auth setup-git และตรวจว่าใช้ Git 2.46 ขึ้นไปตามคำแนะนำ เพื่อให้ gh จัดหาและต่ออายุข้อมูลให้ Git พร้อมหลีกเลี่ยงการเก็บโทเคนเกินอายุ (GitHub Changelog)

คนดูแล CI สคริปต์ และส่วนขยาย

1. ตรวจว่างานใดอ่านผลจาก gh auth token แล้วเก็บไว้ใช้ต่อ หากต้องใช้โทเคนนอก gh ให้ปรับไปอ่านค่าปัจจุบันทุกครั้งที่ต้องใช้ตามคำแนะนำของ GitHub โดยไม่พิมพ์ค่าโทเคนแนบไปในรายงานตรวจงาน (GitHub Changelog)
2. แยกตรวจงานที่ส่งสิทธิ์ผ่าน GH_TOKEN หรือ GITHUB_TOKEN เพราะบันทึกรุ่นบอกชัดว่าโทเคนจากสองช่องทางนี้ไม่ถูกต่ออายุ อย่านำผลทดลองการลงชื่อเข้าใช้บนเครื่องส่วนตัวไปสรุปแทนงานกลุ่มนี้ (GitHub Releases)
3. เก็บทางเลือกเดิมสำหรับงานที่ยังต้องใช้โทเคนอายุยาว และชะลอการเปิดใช้ในงานนั้นก่อนตามคำเตือนของ GitHub หากตั้งค่าให้เลือกแบบหมดอายุเป็นหลักแล้ว คู่มือระบุว่าใช้ --expiring=false ตอนลงชื่อเข้าใช้เพื่อขอแบบไม่หมดอายุได้ แต่ยังต้องตรวจสิ่งที่โฮสต์ออกให้จริง (GitHub Changelog, คู่มือ GitHub CLI)

หัวหน้าทีม เจ้าของกิจการ และผู้ดูแลระบบองค์กร

1. ให้ทีมสรุปผลทดลองเป็นพฤติกรรมที่เห็น เช่น ต่ออายุได้หรือไม่ งานเดิมยังจบหรือไม่ และ Git ยังทำงานได้หรือไม่ ผมแนะนำให้ใช้ข้อมูลเหล่านี้ประกอบการขยายวง เพราะฟีเจอร์ยังเป็นพรีวิวและมีคำเตือนเรื่องสคริปต์เก็บโทเคน (GitHub Changelog)
2. ถ้าใช้ GHES ให้ตรวจรุ่นกับผู้ดูแล โดยประกาศระบุจุดเริ่มรองรับที่ 3.23 สำหรับระบบเก่าต้องรับรู้ว่าการเลือกใช้จะกลับไปได้โทเคนไม่หมดอายุ ไม่ควรบันทึกว่าทั้งองค์กรเปลี่ยนสำเร็จจากการตั้งค่าเพียงอย่างเดียว (GitHub Changelog)
3. หากพบปัญหา ให้บันทึกอาการและเงื่อนไขทดสอบโดยไม่แนบข้อมูลยืนยันสิทธิ์ แล้วรายงานผ่าน issue หรือรายการแจ้งปัญหาในโครงการ cli/cli ตามช่องทางที่ GitHub แนะนำ (GitHub Changelog)

ผมมองว่า…

ผมมองว่า ในความเห็นส่วนตัว การเปลี่ยนครั้งนี้ ไม่ใช่แค่เพิ่มวันหมดอายุ แต่คือการเปลี่ยนวิธีดูแลสิทธิ์ระหว่างงานกำลังเดิน จุดที่มีค่าคือเครื่องมือจัดการต่ออายุให้ ขณะที่โทเคนเข้าถึงที่หลุดมีเวลาสิ้นสุดของตัวเอง เหตุผลนี้ตั้งอยู่บนพฤติกรรมที่ GitHub อธิบาย ไม่ได้แปลว่าเราทราบแล้วว่าความเสียหายจริงจะลดลงเท่าไร (GitHub Changelog)

ผมจะให้น้ำหนักกับการอัปเกรดและทดสอบทีละกลุ่มงานก่อนตั้งเป็นค่าเลือกหลักทั้งทีม เพราะความสะดวกจากการต่ออายุเกิดขึ้นเมื่อเครื่องมือยังมีโอกาสขอค่าปัจจุบัน การเก็บผลลัพธ์ครั้งเดียวแล้วใช้ยาวเป็นพฤติกรรมที่ประกาศเตือนไว้ชัด การตรวจตรงนี้จึงช่วยให้ตัดสินใจได้จากงานจริงของเรา มากกว่าจากคำว่าอัตโนมัติเพียงคำเดียว (GitHub Releases)

ปิดท้าย: สิ่งที่ต้องจับตา

เรื่องที่ควรติดตามต่อคือ GitHub จะเปลี่ยนจากการเลือกเปิดเองไปเป็นค่าเริ่มต้นสำหรับการลงชื่อเข้าใช้ใหม่เมื่อไร ตอนนี้มีเพียงแผนในอนาคต ยังไม่มีวันหรือรุ่นที่ระบุไว้ ระหว่างรอ ทีมที่ใช้ gh ควรทำความเข้าใจว่างานไหนให้เครื่องมือดูแลสิทธิ์ตลอด และงานไหนยังเก็บโทเคนไว้ใช้เอง (GitHub Changelog)

สำหรับธุรกิจในไทยที่ใช้เครื่องมือนี้ ผมแนะนำให้เริ่มจากตรวจวิธีใช้จริงและผลจาก gh auth status เพราะการรองรับขึ้นกับระบบปลายทางด้วย ส่วนตัวเลของค์กรไทยที่ได้รับผลกระทบ อายุโทเคนแบบเจาะจง และกำหนดสิ้นสุดพรีวิว ยังไม่มีในแหล่งข้อมูลชุดนี้ สิ่งที่ยืนยันได้ตอนนี้คือมีทางเลือกใหม่ให้ลอง พร้อมข้อจำกัดที่ต้องอ่านก่อนเปิดใช้กับงานประจำ (คู่มือ GitHub CLI, GitHub Changelog)

Recap

• อัปเกรด GitHub CLI เป็น 2.103.0 ก่อนทดลองฟีเจอร์นี้ (GitHub Releases)
• จำไว้ว่ายังเป็น public preview และเลือกเปิดเองในตอนนี้ (GitHub Changelog)
• ทดลอง gh auth login --expiring แล้วตรวจผลจริงด้วย gh auth status (GitHub Releases)
• อย่าเก็บผลจาก gh auth token ไว้ใช้ยาว ให้อ่านใหม่เมื่อจำเป็นต้องใช้ (GitHub Changelog)
• งานที่ใช้ GH_TOKEN หรือ GITHUB_TOKEN ต้องตรวจแยก เพราะไม่ได้ต่ออายุให้ (GitHub Releases)
• ใช้ Git ผ่าน HTTPS ให้ตั้ง gh auth setup-git และเลือก Git 2.46 ขึ้นไปตามคำแนะนำ (GitHub Changelog)
• ตรวจโฮสต์ด้วย เพราะระบบที่ไม่รองรับจะกลับไปใช้โทเคนไม่หมดอายุ (คู่มือ GitHub CLI)
• ชะลอเปิดใช้กับงานที่ยังต้องพึ่งโทเคนอายุยาว และรายงานปัญหาให้โครงการ cli/cli (GitHub Changelog)