Codex CLI 0.162.0 เพิ่ม managed worktrees และอุดช่อง sandbox policy หลายจุด

OpenAI ออก Codex CLI 0.162.0 วันที่ 8 ตุลาคม 2026 โดยเพิ่มเครื่องมือสร้าง/แสดง managed Git worktrees จาก trusted local projects เมื่อเปิด feature, pin งานใน Command Center, ทำ URL ใน approval/MCP/warning ให้กดได้ และเพิ่มความสามารถ custom model provider หลายส่วนครับ แต่เหตุผลที่รอบนี้น่าสนใจด้านความปลอดภัยคือ bug fixes ของ sandbox: แก้ Linux sandbox เมื่อมี denied files หลายรายการ, ปฏิเสธ executable ที่ใช้สร้าง sandbox หากไฟล์นั้นอยู่ในตำแหน่งที่ sandbox เขียนได้ และกัน config ของ ripgrep ไม่ให้อ่อน deny-glob mask

ผมตรวจ publisher, repository, tag/changelog, metadata ของ npm 0.162.0, release assets, เอกสาร security และ รายการ advisory แบบอ่านอย่างเดียว ไม่ได้ติดตั้ง package, ดาวน์โหลด/รัน binary หรือใช้ remote installer รุ่นนี้ ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ 2026-10-09 ภายใต้เงื่อนไขว่าทีม pin artifact, รักษา sandbox/approval และจำกัด worktree/tool ตาม least privilege

สรุป 30 วินาที

• managed worktree tools ช่วยแยกงานจาก checkout หลัก แต่รับเฉพาะ trusted local projects และเปิดเมื่อ feature ถูก enable
• sandbox fixes ปิด failure mode ที่ policy อาจถูกประกอบด้วย executable จากพื้นที่เขียนได้ หรือ deny glob ถูก config ภายนอกลดความเข้ม
• release ยังปรับ Windows sandbox/temp access และ checksum verification ของ PowerShell installer พร้อมเผย signed installer
• npm integrity ที่ตรวจจาก registry สำหรับ 0.162.0 คือ sha512-qWWckMfknyVym1lD5y2rTwPJA2sgHkzePF2l/Uevss4hVpqbt23rMIHKNTrqECdnv82denylHWEzrAmDnCYNIw==; ต้องเทียบกับช่องทางติดตั้งจริง ไม่เอา digest npm ไปตรวจ binary asset
• advisory ระดับสูงที่พบใน public listing กระทบสายเก่า 0.2.0–0.38.0 และแก้ตั้งแต่ 0.39.0; 0.162.0 อยู่นอก affected range ที่ประกาศ แต่ไม่ได้แปลว่าไม่มี zero-day
• worktree isolation ไม่แทน filesystem sandbox, network policy, secret scoping หรือ human approval สำหรับ push/publish/deploy

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

AI coding agent อ่านไฟล์ เขียนโค้ด และเรียก shell ใน repository ได้ ความเสียหายจากคำสั่งผิดจึงอาจรวมทั้ง source, credential, Git history และ remote service Managed worktree ช่วยให้ agent ทำงานใน checkout แยก เหมือนให้ช่างทำสำเนาห้องทดลองแทนการรื้อห้องหลัก แต่ถ้าช่างยังถือกุญแจคลัง secret และทางออกอินเทอร์เน็ตไม่จำกัด การแยกห้องอย่างเดียวไม่พอ

การปฏิเสธ sandbox-construction executable ที่เขียนได้สำคัญ เพราะตัวสร้างกำแพงต้องเชื่อถือได้ หาก agent หรือ process อื่นแก้ binary ที่ถูกใช้ตั้ง sandbox แล้วระบบเรียก binary นั้นด้วยความไว้วางใจ กำแพงอาจถูกสร้างตามแบบของผู้โจมตี ส่วน ripgrep config เป็นตัวอย่างของ “เครื่องมือช่วยค้น” ที่กลายเป็น policy dependency: ถ้า config เปลี่ยน glob ที่ควรถูกปฏิเสธ การค้นหาอาจเห็นไฟล์ที่ตั้งใจซ่อน

ทีมที่รัน agent ใน CI หรือเครื่องนักพัฒนาจึงควรมอง release นี้เป็นเหตุให้ทบทวน trust boundary ไม่ใช่สัญญาณให้เปิด autonomy มากขึ้นทันที ฟีเจอร์ใหม่เพิ่ม surface และ convenience พร้อมกัน ต้อง rollout แบบ canary และยืนยัน policy ด้วย test ขององค์กรเอง

ทำงานยังไง: ห้องทำงานแยกกับด่านสร้างกำแพง

Git worktree ทำให้ repository เดียวมี checkout หลาย directory ที่ผูก branch/commit แยกกัน Managed tooling ลดงาน manual ตอนสร้างและค้นหา worktree เมื่อเริ่มจาก project ที่ระบบถือว่า trusted ข้อดีคือ uncommitted changes ของงานหนึ่งไม่ปนงานอื่น และ diff/review ชัดขึ้น แต่ Git object database ยังแชร์กัน การลบ branch, hook, config หรือ remote action ต้องมี policy เพิ่ม

Sandbox คือขอบสิทธิ์ runtime เช่นอ่าน/เขียน path ใด เรียก network หรือ process แบบไหน Approval คือด่านตัดสิน action ที่ต้องยกระดับ ทั้งสองชั้นทำงานคนละอย่าง หาก sandbox เปิด workspace-write agent ยังแก้ไฟล์ใน workspace ได้โดยไม่ถามทุกครั้ง; approval มีไว้ก่อนออกนอกขอบที่กำหนด ไม่ใช่ undo หลังคำสั่งทำไปแล้ว

Fix ของ writable sandbox-construction executable ใช้หลัก chain of trust: binary ที่กำหนด isolation ห้ามมาจากพื้นที่ที่ subject ภายใน isolation แก้ได้ Fix ของ ripgrep config ป้องกัน user/project config ไปเปลี่ยน behavior ที่ deny masks พึ่งพา ส่วน Linux denied-files fix ลดโอกาส sandbox start ล้มเมื่อ policy มีหลายไฟล์ ทั้งหมดเป็น defense-in-depth ไม่ใช่หลักฐาน formally verified sandbox

Clickable URL ใน prompt/approval ช่วยตรวจปลายทางก่อนอนุมัติ แต่ URL เองเป็น untrusted input อาจใช้ homoglyph, redirect หรือข้อความ label หลอก ต้องดู hostname จริงและเปิดในบริบทแยก Custom provider ที่เปิด live web/remote compaction เพิ่มข้อมูลออกนอกเครื่อง จึงต้องทบทวน data residency, logging และ credential ของ provider ไม่ถือว่าปลอดภัยเท่า default โดยอัตโนมัติ

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

Release tag อยู่ใน repository openai/codex, ระบุ commit และ changelog พร้อม PR ต่อฟีเจอร์/bug fix Publisher ของ npm คือแพ็กเกจทางการ @openai/codex; registry metadata มี dist integrity ข้างต้น การตรวจนี้ยืนยันความสอดคล้องของ metadata ที่ registry เสิร์ฟ ณ เวลาตรวจ ไม่ได้ทำ reproducible build หรือพิสูจน์ binary ทุกแพลตฟอร์ม

GitHub assets แยกตาม platform และมี digest ใน release metadata ขณะที่ release ระบุ signed PowerShell installer สำหรับ Windows ต้องตรวจ digest/signature ของไฟล์ ที่ดาวน์โหลดจริง ตามช่องทางนั้น ห้ามใช้ npm integrity แทน SHA ของ archive หรือใช้ digest macOS ไปยืนยัน Windows executable

เอกสาร security อธิบายว่า Codex อาศัย sandbox, approval และ network controls ร่วมกัน Public advisory ที่ตรวจไม่มี high/critical ที่ประกาศว่ากระทบ 0.162.0 โดยไม่มี mitigation; CVE ระดับสูงที่เห็นกระทบเวอร์ชันเก่าถึง 0.38.0 และ fix แล้ว แต่ dependency transitive, plugin, MCP server และ custom provider มี advisory คนละชุด ต้องตรวจแยก

Install/update path ถูกตรวจจาก metadata และเอกสารเท่านั้น ไม่ได้รัน npm install, curl-to-shell, PowerShell installer หรือ release binary บน repository จริง ไม่ได้ให้เครื่องมือนี้เข้าถึง credential, private network หรือ production ระหว่างคัดกรอง

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

Managed worktrees ลดค่าเสียเวลาแก้ uncommitted conflict และทำให้ review ต่อ task ชัด แต่เพิ่มพื้นที่ disk, branch/worktree lifecycle และ cleanup หาก automation ทิ้ง worktree ค้าง ทีมต้องกำหนด owner, retention และ archive ที่ recover ได้ ไม่ใช้ recursive delete กว้าง ๆ

Sandbox fix ลด risk ของ policy bypass และ startup failure แต่ rollout อาจกระทบ environment ที่พึ่ง executable/custom rg config ใน path เขียนได้ ซึ่งแท้จริงเป็น configuration ที่ควรแก้ อย่าปิด fix เพื่อให้ pipeline ผ่าน ให้ย้าย binary ไป trusted path และทำ policy explicit

ค่าใช้จ่าย inference/provider อาจเปลี่ยนเมื่อ custom provider เปิด remote compaction หรือ live web ต้องกำหนด budget, telemetry และ data classification ก่อนใช้ ข้อมูล source code/secret ที่ออกผ่าน provider ผิดตัวมีต้นทุน incident สูงกว่าค่า token มาก

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

Release note ระบุ feature managed worktrees เมื่อ feature enabled แต่ไม่ได้บอก policy matrix ของทุก host/config ในหน้าสรุป ทีมต้องทดสอบว่า trusted project ถูกนิยามอย่างไร, symlink/path boundary ถูกจัดการอย่างไร และ cleanup ทำอะไรกับ untracked/ignored file บนระบบจริงของตน

คำว่า reject writable sandbox-construction executables อธิบาย intent แต่ไม่ได้ทำให้ทราบทุก binary ที่เข้า chain บนแต่ละ distribution หรือกรณี mount/ACL พิเศษ Release changelog กับ security docs ตอบคนละระดับ: changelog บอกสิ่งที่แก้ ส่วน docs บอก model การใช้งาน ไม่มีแหล่งใดรับประกันว่า config ขององค์กรไม่มีช่องเปิดเพิ่ม

Advisory list บอกเฉพาะปัญหาที่ถูกรายงาน/เผยแพร่แล้ว และ npm integrity ยืนยัน byte จาก registry ไม่รับรองว่า source ไม่มี malicious dependency หรือบัญชี publisher ไม่มีปัญหาในอนาคต ต้อง monitor release/advisory ต่อเนื่องและมี rollback

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

1. pin 0.162.0 ด้วย lockfile และตรวจ integrity/digest ตามช่องทาง artifact จริง
2. เริ่มใน repository ทดลองที่ไม่มี production secret ใช้ worktree แยกจาก checkout หลักและเก็บ diff ก่อน commit
3. ใช้ filesystem แบบ workspace-write เท่าที่ต้องใช้ ปิด network default แล้ว allowlist ปลายทางเป็นงาน ๆ
4. ห้าม forward environment ทั้งก้อน แยก token อายุสั้น scope ต่ำ และไม่ mount home/cloud credential โดยปริยาย
5. บังคับ approval สำหรับคำสั่งนอก allowlist, push, PR mutation, package publish, deploy และ destructive action
6. pin/allowlist MCP server, plugin และ custom provider แยก ตรวจ publisher/tag/checksum/advisory ของแต่ละตัว
7. ทดสอบ symlink, denied files หลายรายการ, user rg config และ writable PATH ด้วย fixture ปลอดภัยใน sandbox
8. เก็บ audit log ของ tool call, approval, network destination, changed files และ remote side effect พร้อม kill switch

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

ผู้ใช้เดี่ยวควรอัปเดตแบบ pin ใน project ทดลอง เปิด worktree featureเฉพาะเมื่อรู้ว่าจะเก็บ/ลบอย่างไร และอ่าน diff ทุกครั้งก่อน commit ทีมองค์กรควรทำ golden config, policy test และ canary กลุ่มเล็กก่อนบังคับทั้ง fleet จากนั้นเทียบ deny/approval telemetry และสอบสวน unexpected network/tool catalog change

ถ้า environment วันนี้ต้องใช้ bypass approvals หรือ sandbox เพื่อทำงานปกติ ให้ถือเป็นหนี้ด้าน policy ไม่ใช่เหตุให้ rollout อัตโนมัติ แยก capability ที่ขาด สร้าง allowlist แคบ และเพิ่ม approval เฉพาะ action นั้น แทนการเปิด danger-full-access ทั้ง session

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

Prompt injection จาก repository, issue, webpage หรือ MCP result ยังอาจชัก agent ให้ขอ action ที่ดูสมเหตุผล ผู้ใช้อาจกดอนุมัติโดยไม่อ่าน URL หรือ command Managed worktree ยังแชร์ Git object store และอาจเข้าถึง remote/credential ผ่าน host config Sandbox อาจมี platform-specific bug ที่ยังไม่ถูกพบ

MCP server หรือ custom provider ที่เชื่อถือผิดตัวสามารถอ่านข้อความที่ส่งให้มันและคืน instruction อันตราย Secret อาจอยู่ในไฟล์นอก deny pattern, process environment, keychain หรือ ambient cloud identity การผ่านเกณฑ์ครั้งนี้จึงไม่ใช่คำว่า “ปลอดภัยแน่นอน” แต่เป็นหลักฐานว่ารุ่นและ provenance ผ่าน minimum gate ณ วันตรวจ พร้อม residual risks ที่ต้องคุมต่อ

Recap

• ตรวจ tag 0.162.0, npm integrity และ asset digest ตามช่องทางจริง
• ใช้ managed worktree เพื่อแยกงาน แต่ไม่ถือว่าแทน sandbox
• ย้าย sandbox binary ออกจาก path เขียนได้และทดสอบ deny glob
• จำกัด filesystem, network, MCP, provider และ secret แยกชั้น
• human approval ยังจำเป็นกับ remote/destructive side effect
• monitor advisory/dependency และเตรียม rollback
• บันทึก residual risks; สถานะคือผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ

รุ่นนี้มีทั้ง productivity และ hardening ที่จับต้องได้ครับ แต่ประโยชน์สูงสุดเกิดเมื่อทีมใช้ worktree เป็นส่วนหนึ่งของระบบหลายชั้น—artifact ที่ pin, sandbox ที่ทดสอบ, approval ที่อ่านจริง และ remote action ที่ตรวจย้อนกลับได้