Codex CLI 0.160.0 จำสิทธิ์ข้ามเซสชันและเพิ่ม Guardian context—อัปเดตอย่างไรไม่ให้ความสะดวกขยายขอบเขต

Codex CLI 0.160.0 ออกวันที่ 1 ตุลาคม 2026 พร้อมการปรับเรื่อง workspace defaults, การจำ permission เมื่อกลับมาเปิดเซสชัน, Guardian context และการต่อคิวข้อความหลังเครือข่ายกลับมา ฟีเจอร์เหล่านี้ช่วยให้ agent ทำงานต่อเนื่องขึ้น แต่จุดที่ “จำได้” และ “ทำต่อได้” ก็คือจุดที่ทีมต้องตรวจขอบเขตให้ชัดครับ เพราะสิทธิ์ที่เหมาะกับงานเมื่อวานอาจกว้างเกินงานวันนี้

ผมตรวจ release ทางการ, metadata ของ แพ็กเกจ npm, checksum ของไฟล์ release และหน้า security advisories แบบอ่านอย่างเดียว ไม่ได้รัน binary ไม่ได้ติดตั้ง remote script และไม่ได้ให้เครื่องมือแตะ credential หรือ repository จริง ข้อสรุปคือรุ่นนี้ ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ ไม่ใช่คำรับรองว่าไม่มีช่องโหว่ครับ

สรุป 30 วินาที

• รุ่น 0.160.0 เพิ่มการใช้ workspace defaults ในเซสชันที่ไม่ผูก project เมื่อ policy อนุญาต และเก็บ permission ที่ผู้ใช้เคยอนุมัติให้ทำงานต่อเมื่อ resume ได้สะดวกขึ้น
• Guardian แบบ opt-in รับ context จากคำสั่งหรือ handoff ก่อนหน้าได้มากขึ้น ขณะที่ queued message สามารถเดินต่อหลัง reconnect คุณภาพงานต่อเนื่องขึ้น แต่ stale context กับ stale approval จึงเป็นสิ่งที่ต้องทดสอบ
• release แก้ปัญหา sandbox บน Windows และปรับเอกสาร credential storage รายละเอียดเหล่านี้มีผลต่อ boundary จริงมากกว่าฟีเจอร์หน้าตา เพราะเป็นตัวกำหนดว่า agent มองเห็นและทำอะไรได้
• asset สำหรับ macOS arm64 มี SHA-256 ที่ release ระบุ และ npm metadata มี integrity กับ signature ให้ตรวจ provenance ได้ บาง asset มี Sigstore เพิ่มเติม แต่ระดับหลักฐานของแต่ละ platform ไม่เท่ากัน
• advisory ระดับสูง CVE-2025-59532 กระทบรุ่นเก่า 0.2.0–0.38.0 และแก้ตั้งแต่ 0.39.0 รุ่น 0.160.0 อยู่นอกช่วงที่ประกาศ แต่การไม่อยู่ใน advisory เดิมไม่เท่ากับไม่มีความเสี่ยงใหม่
• แนวทางอัปเดตที่ปลอดภัยกว่าคือ pin version, ตรวจ checksum/integrity, ทดสอบใน workspace จำลอง, ตรวจ permission ตอน resume และเริ่มด้วย filesystem จำกัด ไม่มี production secret กับ network ที่เปิดกว้าง

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

AI coding agent แตกต่างจาก autocomplete เพราะมันอาจอ่านหลายไฟล์ แก้โค้ด รัน shell ใช้ network และเรียกเครื่องมือภายนอกได้ เมื่อเครื่องมือจำสิทธิ์และ context ข้ามเซสชัน ประสบการณ์จะลื่นขึ้นเหมือนช่างที่กลับเข้าหน้างานแล้วจำได้ว่ากุญแจห้องไหนเคยใช้ แต่ถ้าช่างถูกย้ายไปงานอีกตึกแล้วพกกุญแจชุดเดิมมาด้วย ความสะดวกนั้นกลายเป็นความเสี่ยงทันที

นักพัฒนาควรสนใจเพราะการ resume งานยาวลดเวลาบอกบริบทซ้ำ แต่ต้องรู้ว่า permission ใดถูกเก็บไว้ ทีมแพลตฟอร์มควรสนใจเพราะ projectless session อาจใช้ค่า default จาก workspace กว้างกว่าที่คาด ทีม security ควรสนใจเพราะ Guardian ได้ context เพิ่ม และทีม compliance ควรสนใจเพราะ queued message หลัง reconnect อาจเกิดขึ้นเมื่อผู้ใช้ไม่ได้กำลังมองหน้าจอ

ผลกระทบไม่ได้แปลว่าฟีเจอร์อันตรายโดยตัวมันเองครับ ปัญหาเกิดเมื่อองค์กรไม่มีนิยามว่า permission มีอายุเท่าไร ผูกกับ directory ไหน และต้องถามใหม่เมื่อ action เปลี่ยนระดับหรือไม่ หากกฎเหล่านี้ชัด การจำ permission ช่วยลด approval fatigue หรืออาการกดอนุมัติจนชินได้ด้วยซ้ำ

ทำงานยังไง: กุญแจห้องเดิมกับสมุดส่งเวร

Workspace defaults เปรียบเหมือนกฎประจำอาคาร เช่น “ช่างเข้าห้องเครื่องได้เฉพาะชั้นนี้” เซสชันที่ไม่ผูก project สามารถหยิบค่าเหล่านี้มาใช้เมื่อ policy อนุญาต จุดดีคือไม่ต้องตั้งใหม่ทุกครั้ง จุดเสี่ยงคือ default ของ workspace ใหญ่เกิน directory งานย่อย หาก root ครอบคลุมหลาย repository ขอบเขตอ่านหรือเขียนอาจกว้างกว่าที่เจ้าของงานคิด

Saved permissions on resume เหมือนกุญแจชั่วคราวที่ยังใช้ได้ตอนกลับเข้ากะ ข้อดีคือ workflow ไม่ติดทุกครั้งที่เปิดงานเดิม ข้อที่ต้องพิสูจน์คือ permission ผูกกับอะไร: thread, project, path, command prefix หรือเวลา หาก checkout เปลี่ยน branch, repository ถูกสลับ, instruction เปลี่ยน หรือ secret ปรากฏใหม่ ระบบควร re-evaluate แทนการถือว่าบริบทเดิมยังถูกต้อง

Guardian context คือผู้ตรวจที่ได้อ่านสมุดส่งเวรจากกะก่อน มีข้อมูลมากขึ้นย่อมตัดสินใจได้ดีขึ้นในหลายกรณี แต่ context เองอาจมีคำสั่งเก่า ข้อสรุปที่หมดอายุ หรือเนื้อหาจากภายนอกที่ไม่ควรถือเป็น authority ทีมควรทดสอบว่าข้อมูล untrusted ใน issue, README หรือเว็บไม่สามารถยกสิทธิ์ตัวเองด้วยประโยคสั่ง agent

Queued messages after reconnect คล้ายใบงานที่ค้างบนสายพาน เมื่อไฟกลับมาสายพานเดินต่อ จุดนี้ช่วยลดงานหาย แต่ action ที่มี side effect ควรตรวจ precondition ใหม่ เช่น branch HEAD ยังเดิมไหม PR ยังเปิดไหม credential ยังมี scope เดิมไหม และคำสั่งยังสอดคล้องกับ user intent ล่าสุดหรือไม่

การควบคุมที่สำคัญจึงไม่ใช่เพียง popup ขออนุญาต แต่เป็นการบังคับ boundary หลายชั้น: filesystem root, sandbox, allowlist คำสั่ง, network egress, secret broker, tool schema และ audit log ถ้าชั้นหนึ่งพลาด ชั้นอื่นควรยังหยุดผลเสียได้

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

หลักฐานแรกคือ tag และ release note ของ repository ทางการ openai/codex รุ่น rust-v0.160.0 ซึ่งระบุฟีเจอร์และ bug fix รอบนี้ ผมยึดรายการจากต้นทาง ไม่ใช้โพสต์สรุปที่ไม่มี tag อ้างอิง

หลักฐานที่สองคือหน้า npm ของ @openai/codex รุ่น 0.160.0 มี metadata ด้าน integrity และ signature สำหรับตรวจว่าแพ็กเกจที่ registry แจกตรงกับสิ่งที่ publisher ลงทะเบียน หลักฐานนี้ช่วยเรื่อง provenance แต่ไม่ได้ตรวจพฤติกรรม runtime ของทุก dependency

หลักฐานที่สามคือ asset release สำหรับ codex-aarch64-apple-darwin.tar.gz แสดง SHA-256 07c3…94b5d ใน metadata ของ release ผมบันทึก prefix/suffix ไว้ในรายงานเพื่อไม่ถมบทความด้วย digest ยาว และไม่ได้ดาวน์โหลดหรือ execute ไฟล์ บาง Linux asset มี Sigstore bundle ให้ตรวจเพิ่ม แต่ไม่ควรเหมารวมว่า asset ทุกตัวมีระดับ signature เท่ากัน

หลักฐานที่สี่คือ security advisory ของ repository พบ CVE-2025-59532 ระดับสูงในช่วง 0.2.0–0.38.0 และ patched ที่ 0.39.0 รุ่น 0.160.0 จึงอยู่นอก affected range ตามประกาศ ณ วันที่ตรวจ อย่างไรก็ตาม advisory เป็นรายการที่รู้แล้ว ไม่ใช่เครื่องสแกนอนาคต

หลักฐานที่ห้าคือ เอกสาร security ของ Codex ซึ่งใช้ตีความ permission และ sandbox ร่วมกับ release note การมีเอกสารช่วยให้ทีมสร้าง policy ได้ แต่ configuration จริงของแต่ละเครื่องยังต้องตรวจเอง

จาก publisher, repository, tag/version, changelog, registry provenance, checksum และ advisory ที่ตรงกัน รุ่นนี้จึง ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ 2026-10-02 โดยมีเงื่อนไขว่าต้องอัปเดตผ่านช่องทางที่ตรวจ provenance ได้และไม่เปิด permission กว้างตามค่า convenience

เงินและผลกระทบ

ฟีเจอร์ resume และ reconnect ลดเวลาซ้ำซ้อนในงานยาว โดยเฉพาะเมื่อ agent ต้องผ่าน test หลายรอบ แต่ประโยชน์ควรวัดเป็นเวลาถึงงานที่ reviewer ยอมรับ ไม่ใช่จำนวนคำสั่งที่ agent รัน หาก saved permission ทำให้เกิดคำสั่งผิด path เพียงครั้งเดียว ค่า recovery อาจมากกว่านาทีที่ประหยัดได้ทั้งสัปดาห์

ทีมควรเก็บตัวชี้วัดอย่าง approval frequency, denied action, command ที่ต้องถามใหม่หลัง resume, stale-context incident, เวลา recovery และสัดส่วนงานที่ผ่าน gate ครั้งแรก ข้อมูลเหล่านี้บอกว่าการลด friction ช่วยจริงหรือเพียงซ่อนจุดที่ระบบถามน้อยลง

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

release note อธิบาย intent ของฟีเจอร์ แต่ไม่ได้แจกแจง matrix ครบว่าการเปลี่ยน context แบบใดทำให้ permission หมดอายุ ทีมจึงต้องทดสอบ branch change, path change, config change และ resume หลังเวลาผ่านไปเองก่อน rollout

checksum และ signature บอกว่าไฟล์มาจากแหล่งที่คาด ไม่ได้บอกว่าไฟล์ไม่มี logic ผิดพลาดหรือ dependency ใหม่ที่มีช่องโหว่ หน้า advisory ก็มีเฉพาะสิ่งที่รายงานแล้ว ความเสี่ยง zero-day และความผิดพลาดในการตั้งค่าองค์กรยังคงอยู่

คำว่า projectless workspace defaults ขึ้นกับ policy ของผู้ใช้ การติดตั้งสองเครื่องอาจมี boundary ต่างกันมากแม้เป็น version เดียวกัน เราจึงสรุปไม่ได้จาก release note ว่าค่า default ในองค์กรใดองค์กรหนึ่งปลอดภัยพอ

การมี Sigstore ในบาง asset แต่ไม่ทุก asset ทำให้วิธีตรวจ provenance ต่างตาม platform ทีม supply chain ควรบันทึกว่าตรวจหลักฐานชนิดใด ไม่ควรเขียนรวมว่า “signed release” หาก artifact ที่ใช้งานมีเพียง checksum หรือ registry signature

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

1. pin ที่ 0.160.0 ในช่วงทดสอบและบันทึก digest/integrity จากช่องทางทางการ อย่าใช้คำสั่ง remote installer ที่ดึง latest โดยไม่เห็น artifact
2. สร้าง workspace จำลองที่ไม่มีข้อมูลลูกค้า ไม่มี production credential และมีไฟล์ canary เพื่อทดสอบว่า agent อ่านออกนอก root หรือส่งข้อมูลออก network ได้หรือไม่
3. ทดลอง resume หลังสลับ branch, เปลี่ยน root, แก้ policy และปิดเปิดเครื่อง ตรวจว่า action เสี่ยงถามใหม่ตามที่องค์กรต้องการ
4. ให้ filesystem write เฉพาะ checkout งาน ปิด network เป็นค่าเริ่มต้น แล้ว allowlist domain เมื่อ workflow ต้องใช้จริง
5. ส่ง secret ผ่าน broker ที่มีอายุสั้นและ scope แคบ ไม่วาง token ใน environment กว้างหรือไฟล์ที่ agent อ่านได้
6. แยก permission อ่าน แก้ไฟล์ รัน test ติดตั้ง dependency push และ deploy คนละระดับ งานย้อนกลับยากต้องให้คนยืนยันใหม่เสมอ
7. บันทึก tool call, path, diff, command, exit code และผู้อนุมัติ โดย redaction ค่า secret ก่อนเข้า telemetry
8. ใช้ branch protection, code review, CI, secret scan และ deployment gate ต่อไป Agent ไม่ควรเป็นข้อยกเว้นของ SDLC

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

แม้จำกัด workspace แล้ว prompt injection ในไฟล์ที่ repository เชื่อถือผิดอาจชักนำ agent ให้เสนอคำสั่งอันตรายได้ แม้ pin version แล้ว publisher account, registry หรือ dependency ก็ยังเป็น supply-chain target แม้ไม่มี high advisory ที่กระทบ 0.160.0 ก็อาจมีช่องโหว่ที่ยังไม่ถูกค้นพบ

human approval เองไม่สมบูรณ์ ผู้ใช้อาจกดอนุมัติเพราะเห็นคำขอบ่อยหรืออ่านข้อความไม่ครบ การลดคำถามด้วย saved permission ช่วยเรื่อง fatigue แต่ทำให้ต้องออกแบบ expiry กับ scope ให้แน่นขึ้น และ Guardian context ที่มากขึ้นอาจเพิ่มทั้งความแม่นกับข้อมูลเก่าที่ไม่ควรเชื่อ

ความเสี่ยงอีกข้อคือ network side effect ต่อให้ filesystem ถูกจำกัด agent อาจเรียก API, สร้าง issue หรือส่งข้อความได้ตามเครื่องมือที่ต่อไว้ จึงต้องจำกัด tool schema กับ credential แยกจาก sandbox ไฟล์เสมอ

ควรทำอะไร

ผู้ใช้เดี่ยวควรอัปเดตใน repository ทดสอบก่อน ตรวจ config และคำขออนุมัติใหม่ทั้งหมด ทีมเล็กควรมี baseline policy กลางกับ checklist หลัง resume องค์กรควร deploy แบบ canary กลุ่มจำกัด พร้อม telemetry ที่ตอบได้ว่า agent ทำอะไรและหยุดอย่างไร หาก policy engine หรือ audit ใช้งานไม่ได้ ให้ fail closed ไม่ใช่เปิดสิทธิ์ชั่วคราวเพื่อให้งานเดิน

ถ้าระบบเดิมอยู่ใน affected range ของ CVE ที่ระบุ การอัปเกรดมีเหตุผลด้าน security เพิ่ม แต่ยังต้องทำตาม supply-chain control เดิม อย่ารีบข้าม checksum และ staging เพียงเพราะรุ่นเก่ากว่าเสี่ยงกว่า

Recap

• รุ่นที่ตรวจคือ Codex CLI 0.160.0 จาก repository และ registry ทางการ
• ตรวจ npm integrity/signature, release checksum และ advisory แบบอ่านอย่างเดียวแล้ว
• รุ่นนี้ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ ไม่ใช่การรับรองว่าปลอดภัยแน่นอน
• ทดสอบ saved permission เมื่อ resume และเมื่อ path/branch/policy เปลี่ยน
• จำกัด filesystem, shell, network, tools และ secret แยกกัน
• ให้ action ย้อนกลับยากถามคนใหม่เสมอ และตรวจ precondition หลัง reconnect
• เก็บ audit ที่ redaction แล้ว พร้อม branch protection และ CI ตามเดิม
• rollout แบบ canary และมี kill switch/rollback ก่อนขยายทีม

0.160.0 น่าสนใจเพราะลดรอยต่อของงานยาวครับ แต่ความต่อเนื่องที่ดีต้องมาพร้อม “ขอบเขตที่ต่อเนื่อง” ด้วย ถ้า permission ผูกกับงานชัด หมดอายุได้ และทุก side effect ยังผ่าน gate ความสะดวกจะช่วยทีมจริงโดยไม่เปลี่ยนกุญแจชั่วคราวให้เป็นมาสเตอร์คีย์ครับ