Gemini CLI 0.62.0 เก็บ OAuth ต่อเนื่องขึ้น แต่ trust กับ sandbox ยังเป็นงานของทีม

Gemini CLI 0.62.0 ออกเมื่อ 29 กันยายน 2026 โดยแก้การเก็บ OAuth refresh token, cleanup ของ PTY และ permission flow ของ MCP tool call ครับ การเชื่อมต่อที่ต่อเนื่องขึ้นลด login ซ้ำได้ แต่ token ที่อยู่ได้นานขึ้นก็ยิ่งต้องถูกเก็บ แยก scope และเพิกถอนอย่างมีวินัย

สรุป 30 วินาที

• release 0.62.0 จาก repository ทางการแก้ไม่ให้ OAuth refresh token สูญหายโดยไม่จำเป็น ปรับ lifecycle/cleanup ของ pseudo-terminal และทำชื่อกับ permission flow ของ MCP tool call ให้มีโครงสร้างขึ้น
• การเก็บ token ต่อเนื่องเป็น reliability fix ไม่ใช่การขยาย permission โดยตั้งใจ แต่เพิ่มเหตุผลให้ตรวจที่เก็บ token, file mode, scope, rotation และ logout/revoke
• เอกสารรุ่นที่ตรึง tag ระบุว่า trusted folders และ sandbox ต้องตั้งค่า/เลือกใช้ตามโหมด ไม่ควรคิดว่าเปิดป้องกันสูงสุดมาอัตโนมัติ
• asset macOS arm64 ที่ตรวจถูกระบุว่า unsigned จึงมี residual risk เพิ่ม แม้มี SHA-256 ใน release metadata; รอบนี้ไม่ดาวน์โหลดหรือรัน artifact
• 0.62.0 ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ สำหรับ canary แบบเปิด folder trust, sandbox, egress allowlist และ MCP ทีละตัว ไม่ใช่คำรับรองว่าปลอดภัยแน่นอน

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

OAuth refresh token เปรียบเหมือนบัตรเติมเที่ยวอัตโนมัติครับ access token ใบปัจจุบันหมดอายุแล้ว refresh token ขอใบใหม่ได้ ผู้ใช้ไม่ต้อง login บ่อยจึงทำงานลื่นขึ้น แต่ถ้าบัตรหลักถูกขโมย ผู้โจมตีอาจต่ออายุการเข้าถึงได้จนกว่าจะ revoke การแก้ไม่ให้ token หายจึงดีด้านประสบการณ์ แต่ทีมต้องมอง lifecycle ครบตั้งแต่สร้าง เก็บ ใช้ หมุน และทำลาย

PTY หรือ pseudo-terminal คือชั้นที่ทำให้ agent คุยกับโปรแกรม command line แบบ interactive ได้ ถ้า lifecycle ไม่สะอาด process อาจค้าง file descriptor ไม่คืน หรือ output มาถึงผิด session การแก้ cleanup ช่วย reliability และลด state หลอน แต่ไม่ได้ป้องกัน command อันตรายด้วยตัวเอง Permission ต้องตัดสินก่อน spawn และ sandbox ต้องจำกัดผลลัพธ์ตอนรัน

MCP เปิดทางให้ agent เรียกเครื่องมือภายนอก ตั้งแต่ค้นเอกสารถึงแก้ ticket ชื่อ tool call ที่เป็นโครงสร้างและ prompt อนุมัติที่ชัดขึ้นช่วยให้คนรู้ว่าจะเกิดอะไร แต่ server สามารถประกาศชื่อสวยแล้วทำงานกว้างกว่าที่คาดได้ จึงต้องตรวจ implementation, arguments, credential และ network ไม่ใช่ดู label อย่างเดียว

ทำงานยังไง: สามด่านก่อนกุญแจจะไขประตู

ลองนึกถึงอาคารสำนักงาน ด่านแรกถามว่าเราเชื่อถือ “สถานที่” นี้ไหม นี่คือ trusted folder ซึ่งควรป้องกัน repository แปลกหน้าจากการโหลด config, extension, environment หรือ MCP โดยทันที ด่านที่สองคือ sandbox จำกัดว่ากระบวนการอ่าน/เขียนที่ไหนและออก network ได้อย่างไร ด่านที่สามคือ permission ของ tool/action เฉพาะครั้ง

เอกสาร trusted folders ของ tag 0.62.0 ต้องถูกอ่านคู่กับการตั้งค่าจริง เพราะฟีเจอร์ trust อาจไม่ได้เปิดตาม default ที่ผู้ใช้เดา เมื่อ folder ไม่ได้รับ trust สิ่งจาก workspace ควรถูกจำกัด แต่ทีมต้องทดสอบด้วย config และ MCP ปลอมว่าระบบ fail-closed จริงใน deployment ของตน

เอกสาร sandbox แสดงหลายทางเลือก การเปิด sandbox ไม่ได้แปลว่า network ปิดทุกโหมด โปรไฟล์ที่ permissive หรือ proxy กว้างยังส่งข้อมูลออกได้ และ path mount อาจพา credential เข้า process ได้ ให้ตรวจ policy ที่ effective ไม่ใช่ชื่อโหมด

ในชั้น OAuth 0.62.0 รักษา refresh token ให้ session ต่อเนื่องขึ้น การทำที่ถูกต้องคือจัดเก็บใน mechanism ของระบบปฏิบัติการหรือไฟล์ที่ permission แคบ แยก account สำหรับ agent จากบัญชีมนุษย์ ให้ scope เท่าที่ tool ต้องใช้ และมีคำสั่ง revoke ที่ทดสอบแล้ว เมื่อ logout ต้องตรวจทั้ง access token, refresh token และ session cache

ในชั้น MCP release นี้ปรับ structured tool call title กับ permission flow จุดดีคือ UI สามารถบอก action ได้ชัดขึ้น แต่ enforcement ต้องอ้าง server identity และ arguments ด้วย หาก server เปลี่ยน binary หลัง approval หรือ command ชี้ package แบบ floating tag ความหมายของชื่อเดิมอาจเปลี่ยนโดยผู้ใช้ไม่เห็น

หลักฐานที่ตรวจ

ตรวจ repository google-gemini/gemini-cli, tag และ release v0.62.0 ซึ่งเผยแพร่ 29 กันยายน 2026 พร้อมเอกสาร trusted folders/sandbox ที่ตรึงกับ tag เดียวกัน และ security advisories ณ 1 ตุลาคม 2026 การตรึงลิงก์ด้วย version ช่วยไม่ให้เอกสารจาก main เปลี่ยนแล้วอธิบายคนละ behavior กับ binary

release metadata แสดง SHA-256 ของ gemini-darwin-arm64-unsigned.zip เป็น 050d9e3a53e6fc9cc2c00cd7d6771d72077b8fa2c0d1ec925ce3c353ee94b55b ชื่อ asset ระบุชัดว่า unsigned นี่เป็นหลักฐาน provenance ที่อ่อนกว่าชุดที่มีลายเซ็นตรวจสอบได้ รอบนี้จึงตรวจ metadata อย่างเดียว ไม่ดาวน์โหลด ไม่แตกไฟล์ ไม่รัน installer และไม่ต่อ credential

หน้า advisory สาธารณะไม่พบ known high/critical advisory ที่ระบุว่ากระทบ 0.62.0 โดยไม่มี mitigation ณ เวลา verifiedAt แต่มีข้อจำกัดเดิม: disclosure อาจตามหลังการค้นพบ และ dependency advisory บางตัวอาจไม่ได้ขึ้นหน้า repository ทันที ต้องสแกน lockfile/SBOM ของ artifact ที่องค์กรเลือกติดตั้งอีกชั้น

publisher, repository, tag/version และ changelog ชัดเจน เอกสารขอบเขตสิทธิ์มีให้ตรวจ รุ่นนี้จึงผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ สำหรับการทดลองจำกัดสิทธิ์ โดยถือ unsigned artifact เป็น residual risk ที่ต้องหลีกเลี่ยงหรือชดเชยด้วยช่องทางติดตั้งที่ผู้ผลิตลงนามและตรวจได้

วิธีใช้ให้ปลอดภัยขึ้น

เลือกช่องทางติดตั้งทางการที่มี provenance/signature ชัดกว่า unsigned asset ถ้ามี ตรึง 0.62.0 และตรวจ digest/SBOM ก่อนใช้งาน ห้าม pipe remote script เข้า shell เริ่มใน container หรือ disposable account ที่ไม่มี production secret และ mount เฉพาะ worktree จำลองแบบ read-only ก่อน

เปิด trusted folders แล้วทำ negative test: ใส่ workspace config, .env, extension และ MCP ปลอมใน folder ที่ไม่ trust ตรวจว่าทั้งหมดไม่ถูกโหลด เปิด sandbox แบบ restrictive ปิด network แล้วเพิ่ม egress allowlist เฉพาะ API ที่ต้องใช้ อย่าใช้ flag ข้าม trust ใน CI เป็นค่าเริ่มต้น

สำหรับ OAuth ใช้บัญชี agent แยก scope ต่ำ อายุ session สั้น เก็บ token ใน secret store/file mode ที่เหมาะสม และทดสอบ revoke จากฝั่ง provider หลัง logout ตรวจ log, crash dump และ backup ไม่ให้มี refresh token สำหรับ MCP ให้เพิ่มทีละ server ตรึง package digest ตรวจ command กับ arguments และตั้ง approval สำหรับ write/shell/external message

บังคับ branch protection, tests, secret scan และ human review ภายนอก Gemini CLI ถ้างานไม่ต้องเขียนไฟล์ให้ read-only ถ้าไม่ต้องใช้ shell ให้ปิด shell และถ้าต้องเรียกข้อมูล production ให้ใช้ read replica กับ query allowlist แทน credential เต็มฐาน

ความเสี่ยงคงเหลือ

refresh token ที่คงอยู่เพิ่มหน้าต่างการขโมยหาก storage หรือ backup หลุด Unsigned asset ทำให้การพิสูจน์ผู้สร้าง artifact อ่อนลงแม้ checksum ตรงกับ GitHub metadata และ checksum เองไม่บอกว่าโค้ดปลอดภัย

trusted folder กับ sandbox ต้องเปิด/ตั้งค่าอย่างถูกต้อง โปรไฟล์ permissive อาจมี network กว้าง MCP server และ extension มี dependency chain ของตัวเอง Structured title อาจทำให้ approval อ่านง่ายขึ้นแต่ไม่รับรองว่าคำอธิบายตรง behavior จริง Prompt injection จาก repository หรือผลค้นเว็บยังล่อให้ agent ขอสิทธิ์เพิ่มได้

งานศึกษาการโจมตีผ่าน tool poisoning ใน MCP clients รวม Gemini CLI อยู่ในขอบเขตและชี้ว่าต้องมอง parameter visibility, warning, sandbox กับ audit logging ร่วมกัน งานนี้ไม่ได้ทดสอบ 0.62.0 โดยเฉพาะ จึงใช้เป็นหลักฐานว่าความเสี่ยง prompt injection มีอยู่จริงและเป็นกรอบออกแบบ negative test ไม่ใช่คำตัดสินว่ารุ่นนี้มีช่องโหว่เดียวกับทุกเวอร์ชันที่งานวิจัยสำรวจ

PTY cleanup ลด process ค้างแต่ terminal command ยังสร้าง child process, daemon หรือ file/network side effect ได้ เราไม่ได้รัน binary จึงยังไม่ยืนยัน cleanup และ revoke behavior บนเครื่องจริง อีกทั้ง advisory ใหม่อาจเผยแพร่หลังวันที่ตรวจ

สิ่งที่ยังไม่ชัด และแหล่งข่าวพูดไม่ตรงกันตรงไหน

release note บอกว่า refresh token ถูกเก็บได้ถูกต้องขึ้น แต่ไม่ได้ให้ threat model หรือ path ของ token สำหรับทุกระบบปฏิบัติการในข้อความสั้น ต้องตรวจเอกสาร authentication และ filesystem ของ installation จริง เอกสาร trusted folders/sandbox บอก capability แต่ค่า effective ยังขึ้นกับ settings ของผู้ใช้

ชื่อ asset “unsigned” เป็นข้อมูลตรงจาก release ไม่ได้แปลว่า release เป็นมัลแวร์ แต่ก็ไม่ควรถูกทำให้เบาลงว่า checksum เท่ากับ signature ส่วนหน้า advisory ไม่พบรายการที่กระทบไม่ได้แปลว่า dependency ทั้งหมดไม่มี CVE

ควรทำอะไร

นักพัฒนาควรทดลองใน repository จำลอง ทีม platform ควรแจก baseline config ที่เปิด trust/sandbox และปิด egress ทีม security ควรตรวจ token at rest, revoke, artifact provenance และ MCP inventory ส่วนเจ้าของระบบควรให้ permission ที่เปลี่ยนข้อมูลต้องมีคนอนุมัติและมี rollback

Recap

• ตรึง 0.62.0 และเลือก artifact/channel ที่ยืนยันลายเซ็นได้
• เปิด trusted folders และทำ negative test ก่อนเชื่อ repository ภายนอก
• ใช้ restrictive sandbox กับ egress allowlist
• แยก OAuth account/scope และทดสอบ logout กับ revoke refresh token
• เพิ่ม MCP ทีละตัว ตรึง digest และอ่าน arguments ก่อนอนุมัติ
• ใช้ branch protection, tests, secret scan และ review เป็น publication gate

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