Copilot CLI 1.0.100 ปิด telemetry ได้ แต่กดข้าม sandbox ต้องคิดก่อน

Copilot CLI รุ่น 1.0.100 ลงวันที่ 19 ตุลาคม 2026 เพิ่มตัวเลือกปิดการอัปโหลด telemetry จากตัวโปรแกรม และปรับกฎขออนุญาตหลายจุดที่เกี่ยวกับไฟล์กับคำสั่งบนเครื่องผู้ใช้โดยตรง (GitHub Release) สำหรับคนที่ให้ AI ช่วยแก้งาน ประเด็นจึงอยู่ที่ข้อมูลอะไรถูกส่งออก และเรากำลังยอมให้ผู้ช่วยทำอะไรกับงานของเราบ้างครับ

GitHub อธิบายว่า Copilot CLI คือการใช้ Copilot ผ่าน terminal หรือหน้าต่างพิมพ์คำสั่งบนคอมพิวเตอร์ ผู้ใช้สั่งให้ช่วยแก้บั๊ก เพิ่มความสามารถ หรือสร้างแอปได้ และระหว่างทำงานมันอาจอ่าน แก้ไข และเรียกใช้ไฟล์ในโฟลเดอร์ที่เราอนุญาต รวมถึงโฟลเดอร์ย่อย (GitHub Docs) คนทำเว็บร้านค้า นักศึกษาที่ทำโปรเจกต์ หรือคนดูแลระบบจึงควรอ่านคำขออนุญาตให้เป็น ก่อนฝากงานจริงไว้กับมัน

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

อัปเดตรอบนี้มีของที่เกี่ยวกับชีวิตประจำวันของคนทำงานกับ AI อยู่หลายชิ้น ผมคัดส่วนที่ควรเข้าใจก่อนใช้งานดังนี้

• เพิ่ม --disable-client-telemetry เพื่อปิดการอัปโหลด telemetry หรือข้อมูลรายงานการใช้งานจากตัว CLI ตามขอบเขตที่บันทึกรุ่นระบุ (GitHub Release)
• เพิ่ม --trust-folder สำหรับงานสั่งครั้งเดียวผ่านโหมด prompt โดย prompt คือข้อความสั่งงาน รองรับทั้งการเริ่มด้วย -p และรับข้อความที่ส่งต่อมาจากโปรแกรมอื่น (GitHub changelog)
• กฎอนุญาตเครื่องมือใน Skill ซึ่งเป็นชุดคำแนะนำและทรัพยากรสำหรับงานเฉพาะทาง จัดการเครื่องหมายจุลภาคในอาร์กิวเมนต์ได้ถูกต้องขึ้น และกฎที่ไม่ระบุขอบเขตซึ่งอ่านโครงสร้างแล้วกำกวมจะถามผู้ใช้ แทนการให้สิทธิ์ไปเลย (GitHub changelog)
• เมื่อคำสั่งใน sandbox หรือพื้นที่จำกัดการเข้าถึง เจอปัญหาความเชื่อถือใบรับรองของระบบส่งต่อข้อมูลยืนยันตัวตน โปรแกรมจะอธิบายปัญหา และอาจเสนอให้รันใหม่นอก sandbox โดยต้องได้รับอนุมัติ (GitHub Release)
• การโหลดเครื่องมือจาก MCP server ที่ค้างจะไม่ทำให้เซสชันหยุดรอเป็นนาที ๆ อีกตามบันทึกรุ่น โดย MCP คือช่องทางเชื่อมผู้ช่วยกับเครื่องมือหรือบริการภายนอก (GitHub changelog)

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

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

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

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

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

ทำงานยังไง

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

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

ตัวเลือก --trust-folder ใหม่ทำให้บอกความเชื่อถือโฟลเดอร์ได้ในงานแบบสั่งครั้งเดียว ผ่าน -p หรือ piped stdin ซึ่งหมายถึงการรับข้อความที่โปรแกรมอื่นส่งเข้ามา จุดที่ควรจำคือมันเกี่ยวกับการบอกว่าโฟลเดอร์นี้ยอมให้ผู้ช่วยทำงานด้วยได้ บันทึกรุ่นไม่ได้บอกว่าตัวเลือกนี้อนุญาตเครื่องมือทุกชนิดโดยอัตโนมัติ (GitHub changelog)

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

สำหรับเครือข่ายองค์กร proxy คือระบบตัวกลางที่รับส่งการเชื่อมต่อแทนเครื่องเรา รุ่นนี้ทำให้การรับส่งข้อมูลตามกฎโฮสต์ของ sandbox เคารพค่า HTTPS_PROXY และ HTTP_PROXY เมื่อไม่ได้ตั้ง proxy ของ sandbox ไว้ โฮสต์ในที่นี้หมายถึงปลายทางที่เชื่อมต่อ (GitHub changelog) ทีม IT จึงควรทดสอบกรณีที่บริษัทใช้ตัวกลางเครือข่ายอยู่แล้ว แทนการสรุปว่าพฤติกรรมเหมือนเดิมทุกจุด

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

จุดหักมุม: ถามน้อยลงบางงาน แต่ถามมากขึ้นเมื่อกฎกำกวม

อัปเดตนี้ไม่ได้เพิ่มหรือลดคำถามอนุญาตไปในทิศทางเดียว ฝั่งกฎ allowed-tools ซึ่งใช้ระบุเครื่องมือที่ Skill ใช้ได้ มีการเก็บจุลภาคภายในอาร์กิวเมนต์หรือข้อมูลประกอบคำสั่งไว้ตามเดิม แทนการแยกผิดเป็นหลายส่วน หากโครงสร้างรายการกำกวม กฎที่ไม่ระบุขอบเขตจะเปลี่ยนมาถาม แทนการให้สิทธิ์ (GitHub changelog) ผมมองว่านี่ช่วยลดโอกาสที่การอ่านกฎผิดจะกลายเป็นการอนุญาตเกินเจตนา

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

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

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

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

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

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

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

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

หน้า release กับ changelog ระบุรุ่น 1.0.100 และวันที่ 19 ตุลาคม 2026 ตรงกันในข้อความที่ให้มา ส่วนหน้า release แสดงเวลา 18:43 แต่ไม่มีเขตเวลาประกอบ จึงไม่ควรแปลงเป็นเวลาไทยหรือสรุปวันตามเวลาไทยจากตัวเลขนั้น (GitHub Release, GitHub changelog) บทความนี้ใช้วันที่ตามบันทึกรุ่นเท่านั้น บริการติดตามรุ่นซอฟต์แวร์อิสระอย่าง NewReleases ก็บันทึกรุ่น v1.0.100 วันที่ 2026-10-19 พร้อมรายการ --disable-client-telemetry และ --trust-folder ตรงกัน (NewReleases) แต่หน้านี้คัดลอกบันทึกรุ่นจากคลังทางการ จึงยืนยันได้แค่ว่าข้อความประกาศตรงกัน ไม่ได้เป็นการทดสอบแยกครับ

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

คำว่า verified ในการติดตั้ง Skills และปลั๊กอินจากลิงก์ติดตั้งของ GitHub ก็มีขอบเขตที่ต้องระวัง บันทึกรุ่นระบุว่ารองรับการติดตั้งรายการที่ผ่านการยืนยัน แต่ไม่ได้ให้รายละเอียดว่าตรวจอะไร ใครตรวจ หรือรับประกันพฤติกรรมหลังติดตั้งแค่ไหน (GitHub Release) จึงไม่ควรขยายความเป็น “ตรวจแล้วไม่มีความเสี่ยง”

ยังไม่ทราบว่ามีองค์กรไทยได้รับผลกระทบจากปัญหาเดิมหรือไม่ และไม่มีข้อมูลเปรียบเทียบการส่งข้อมูลก่อนกับหลังใช้ตัวเลือกปิด telemetry ในข้อความต้นทาง เรามีหลักฐานการประกาศเปลี่ยนแปลงจากผู้พัฒนา แต่ยังไม่มีผลทดสอบอิสระในชุดแหล่งข้อมูลนี้

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

ผู้เริ่มใช้ นักศึกษา และคนทำงานทั่วไป

1. เริ่มจากโครงการทดลองที่ทิ้งได้ ใช้ข้อมูลจำลอง และอย่าใส่ข้อมูลรับรองของระบบใช้งานจริง เช่น รหัสผ่านหรือโทเคนที่ใช้เข้าระบบ ผมแนะนำให้ทำแบบนี้ก่อนเริ่มสำรวจความสามารถของผู้ช่วย
2. อ่านคำยืนยันโฟลเดอร์ให้ครบ เลือกอนุญาตเฉพาะเซสชันก่อนถ้ายังไม่แน่ใจ เอกสารมีทั้งตัวเลือกเฉพาะครั้งและตัวเลือกจำโฟลเดอร์ในอนาคต (GitHub Docs)
3. พิจารณาตัวเลือก --disable-client-telemetry หากต้องการปิดการอัปโหลดข้อมูลรายงานจากตัว CLI และจดขอบเขตนี้ไว้ให้ตรงกับบันทึกรุ่น (GitHub Release)
4. ถ้าไม่ยอมรับคำสั่งที่เสนอ ให้ปฏิเสธพร้อมบอกแนวทางใหม่ได้ เอกสารระบุว่าสามารถให้ความเห็นประกอบการปฏิเสธ เพื่อให้ Copilot ปรับวิธีทำงาน (GitHub Docs)

นักพัฒนาและผู้ดูแลโครงการ

1. ทดลองรุ่น 1.0.100 กับงานขนาดเล็กก่อน แล้วตรวจสิทธิ์ที่ร้องขอและผลแก้ไขด้วยตัวเอง โดยใช้เลขรุ่นกับวันที่จากหน้า release เป็นจุดอ้างอิง (GitHub Release)
2. ทบทวนกฎเครื่องมือของ Skills โดยเฉพาะรายการที่กำกวม เพราะรุ่นนี้เปลี่ยนกฎไม่ระบุขอบเขตบางกรณีให้ต้องถามผู้ใช้ (GitHub changelog)
3. ตรวจคำแนะนำเฉพาะส่วนของโครงการให้เป็นปัจจุบัน เนื่องจากบันทึกรุ่นระบุว่าจะนำมาใช้โดยอัตโนมัติเมื่ออ่านหรือแก้ไฟล์ที่ตรงกัน (GitHub changelog)
4. ถ้าพบข้อเสนอให้รันนอก sandbox ให้หยุดอ่านคำสั่งและสิทธิ์ก่อน การรันซ้ำแบบนี้ต้องได้รับอนุมัติตามบันทึกรุ่น ผมแนะนำให้หาสาเหตุด้านใบรับรองก่อนตัดสินใจออกจากข้อจำกัด (GitHub Release)

ทีม IT และเจ้าของธุรกิจ

1. ทดสอบ proxy กับนโยบายองค์กรในสภาพแวดล้อมทดลอง โดยตรวจกรณีไม่มี proxy ของ sandbox เพราะเป็นเงื่อนไขที่การรองรับตัวแปร proxy ใหม่มีผล (GitHub changelog)
2. ตรวจบริการภายในที่เครื่องทดลองเข้าถึงได้ด้วย รุ่นนี้ระบุว่า sandbox อนุญาตเครือข่ายภายในโดยค่าเริ่มต้น เพื่อให้คำสั่งเข้าถึงบริการบนเครื่องและเครือข่ายส่วนตัวได้ (GitHub Release)
3. กำหนดผู้รับผิดชอบอนุมัติส่วนเสริมและขอบเขตงานก่อนใช้กับข้อมูลจริง ผมแนะนำให้บันทึกสิ่งที่อนุญาตไว้ให้คนในทีมเข้าใจตรงกัน
4. อย่าใช้การเปิดสิทธิ์ทั้งหมดเป็นขั้นตอนเริ่มต้น เอกสารมีตัวเลือกเปิดทุกสิทธิ์พร้อมกัน แต่ยังเตือนถึงผลด้านความปลอดภัยของการอนุมัติเครื่องมือทั้งเซสชันด้วย (GitHub Docs)

หลักฐานความปลอดภัยและความเสี่ยงที่ยังเหลือ

ด้านที่มา เรามีหน้า release ของคลังทางการ github/copilot-cli พร้อมแท็ก v1.0.100 และวันที่เผยแพร่ตามแหล่งข้อมูล 19 ตุลาคม 2026 โดย changelog ระบุรุ่นและวันตรงกัน (GitHub Release, GitHub changelog) หลักฐานนี้ช่วยยืนยันว่าการเปลี่ยนแปลงมาจากประกาศของโครงการ แต่ไม่ได้ทดแทนการประเมินความปลอดภัยในระบบของเรา

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

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

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

ผมมองว่า…

ผมมองว่า คุณค่าของอัปเดตนี้ ไม่ใช่การทำให้ AI ขออนุญาตน้อยที่สุด แต่คือการทำให้สิทธิ์ตรงกับสิ่งที่เจ้าของงานตั้งใจ นี่เป็นความเห็นของผมจากการอ่านแหล่งข้อมูล ไม่ใช่ผลทดสอบความปลอดภัย การถามเมื่อกฎกำกวมและการบอกเหตุผลเมื่อ sandbox ทำงานติดขัด ช่วยให้ผู้ใช้มีข้อมูลตัดสินใจมากกว่าปุ่มอนุญาตลอย ๆ

ส่วนตัวเลือกปิด telemetry ผมเห็นว่าเป็นสิ่งที่ควรมีให้เลือก แต่ความเป็นส่วนตัวต้องอาศัยความเข้าใจขอบเขตด้วย คนใช้ควรรู้ว่าปิดรายงานอะไร แล้วค่อยตัดสินใจว่าจะให้งานและข้อมูลแบบไหนกับผู้ช่วย ความสะดวกมีค่าครับ แต่ปุ่มที่กดง่ายก็ยังควรอ่านก่อนกด

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

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

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

Recap

• ตรวจรุ่นที่ใช้เทียบกับ Copilot CLI 1.0.100 ตามประกาศวันที่ 19 ตุลาคม 2026 (GitHub Release)
• เข้าใจว่า --disable-client-telemetry ปิดการอัปโหลด telemetry จากตัว CLI ตามขอบเขตประกาศ (GitHub Release)
• แยกการเชื่อถือโฟลเดอร์ออกจากการอนุมัติเครื่องมือ และเลือกสิทธิ์ให้เหมาะกับงาน (GitHub Docs)
• ตรวจ Skills และกฎเครื่องมือที่กำกวม ซึ่งรุ่นนี้ปรับให้ถามในกรณีที่ระบุไว้ (GitHub changelog)
• อ่านข้อเสนอรันนอก sandbox ทุกครั้ง เพราะต้องอนุมัติและคำสั่งจะออกจากข้อจำกัดนั้น (GitHub Release)
• ทดสอบ proxy และการเข้าถึงเครือข่ายภายในให้ตรงกับนโยบายทีม (GitHub changelog)
• เริ่มจากโครงการทดลองที่ทิ้งได้ และไม่ใช้ข้อมูลรับรองของระบบใช้งานจริง
• ไม่ตีความว่าหน้านโยบาย security ที่ไม่มีรายละเอียด advisory ในข้อความนี้ยืนยันว่าไร้ช่องโหว่ (GitHub Security)