Codex CLI 0.158.0: เพิ่ม MCP OAuth secret และอุดขอบ sandbox หลายระบบ

Codex CLI 0.158.0 ออกเมื่อ 28 กันยายน 2026 พร้อมฟีเจอร์ที่แตะทั้ง terminal UX, MCP authentication, exec-server และ image editing ขณะเดียวกัน release นี้แก้ขอบ sandbox บน Windows/Linux และการรักษา metadata ของ Git หลายจุด จึงเป็นรุ่นที่ควรอ่านในฐานะ การเปลี่ยนพื้นผิวสิทธิ์ ไม่ใช่ดูเพียงรายการความสะดวกใหม่ครับ

ผมตรวจ tag และ asset จาก release ทางการ, เอกสาร Codex security, หน้า security advisories ของ repository และ source repository แบบอ่านอย่างเดียว ไม่รัน installer, binary หรือ agent ที่ดาวน์โหลดมาใน repository นี้ ผลต่อไปนี้คือการคัดกรอง ณ เวลา verifiedAt ไม่ใช่การรับรองความปลอดภัยถาวร

สรุป 30 วินาที

• 0.158.0 เพิ่ม MCP OAuth client secret, bearer token สำหรับ exec-server websocket และรองรับงานแก้ภาพที่ใช้ไฟล์พร้อมพื้นหลังโปร่งใส
• terminal มี copy-on-select/right-click paste และ approval สำหรับ terminal input ในคำสั่ง elevated เปิดเป็นค่าเริ่มต้น
• แก้ Windows sandbox path, credential และ policy size; แก้ nested writable roots บน Linux; รักษาการป้องกัน Git metadata และ alias บน macOS
• publisher, repository, tag, changelog และ artifact digest ตรวจสอบย้อนกลับได้ จึงผ่าน provenance gate
• ไม่พบ high/critical advisory ที่หน้า official advisories ระบุว่ากระทบ 0.158.0 โดยไม่มี mitigation ณ เวลาตรวจ แต่ absence of advisory ไม่ใช่หลักฐานว่าไม่มีช่องโหว่
• ผลสรุป: ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ โดยยังต้องใช้ sandbox, approval และ credential scope ที่แคบ

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

coding agent อ่านไฟล์ เรียก shell ออก network และคุยกับ MCP server ได้ การเพิ่ม authentication option ทำให้เชื่อมระบบองค์กรได้สะดวกขึ้น แต่ทุกช่องเชื่อมใหม่คือเส้นทาง credential ใหม่ด้วย หาก client secret ถูกใส่ใน config ที่ commit หรือ bearer token ถูกส่งผ่าน log ความเสียหายเกิดนอก sandbox ได้แม้ filesystem ถูกจำกัดดี

release ที่แก้ sandbox หลาย platform ควรถูกพิจารณาเร่งอัปเดต โดยเฉพาะทีม Windows และ Linux ที่ใช้ nested writable roots แต่การอัปเดตก็เปลี่ยน behavior ของ approval และ terminal input ทีมต้องทดสอบ workflow จริง ไม่ใช่เปิด rollout ทั้งองค์กรทันที

คนที่ไม่ใช้ exec-server หรือ image editing ก็ยังได้รับผลจาก terminal UX เช่น right-click paste การ paste คำสั่งโดยไม่ตั้งใจเป็น human-factor risk โดยเฉพาะคำสั่งหลายบรรทัด การมี approval เพิ่มในเส้นทาง elevated ช่วยได้ แต่ shell ที่ไม่ elevated ยังทำความเสียหายใน workspace ได้ตาม permission

ทำงานยังไง

Codex แยก policy หลายชั้น: sandbox จำกัด resource ที่ process เข้าถึง, approval ขอมนุษย์ก่อน action บางชนิด และ instruction กำหนดขอบเขตงาน ลองเทียบพนักงานถือคีย์การ์ด: prompt คือใบงาน, approval คือหัวหน้าเซ็น, sandbox คือประตูที่คีย์เปิดได้จริง หากใบงานถูกหลอก แต่คีย์เปิดได้แค่ห้องทดสอบ blast radius ยังเล็กกว่าการถือ master key

MCP OAuth client secret ช่วย client ยืนยันตัวกับ authorization flow ที่ต้องใช้ confidential client ส่วน bearer token ของ exec-server websocket ใช้ยืนยัน connection ไปยัง service ที่รันคำสั่ง ความปลอดภัยจึงพึ่งทั้ง transport, token scope, lifetime, storage และ server-side authorization การมี token ไม่ได้ทำให้ทุก message จาก connection นั้นสมควรถูก execute

nested writable roots คือกรณี sandbox อนุญาตเขียนบาง path ซ้อนอยู่ใต้ path อื่น การ canonicalize path, symlink และ mount ไม่ถูกต้องอาจทำให้ policy แคบใน config แต่กว้างจริง รุ่นนี้มี fix บน Linux ซึ่งเป็นสัญญาณให้ทีมเพิ่ม regression test ของ root ซ้อน, symlink และ Git metadata ใน environment ของตน

การรักษา Git metadata protection สำคัญเพราะไฟล์ใน .git สามารถเปลี่ยน hook, ref หรือ config จน action ภายหลังทำสิ่งไม่คาดคิดได้ Workspace write ไม่ควรถูกตีความว่าเขียน metadata ได้ทุกอย่าง และการแก้ใน release notes ควรถูกทดสอบด้วย policy audit โดยไม่พยายาม exploit repository production

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

Tag rust-v0.158.0 ถูกเผยแพร่ใน repository openai/codex ที่เป็นต้นทางทางการและ release ไม่ถูกทำเครื่องหมาย prerelease ผมบันทึก version, เวลาเผยแพร่ และรายการเปลี่ยนแปลงจากหน้า release โดยตรง ไม่อาศัยโพสต์ aggregator เป็นหลัก

Asset codex-aarch64-apple-darwin.tar.gz แสดง digest SHA-256 เป็น 341c4a08f9ce1935b3007376dc2a3d50a0a89112930e9a474ae61367218f6e8a และ asset codex-package_SHA256SUMS แสดง digest 372f97579654ead4b6ed968afde6ea662348e70d4e03939b6f68e37101a58354 ค่านี้เป็นหลักฐานสำหรับตรวจ artifact ที่ดาวน์โหลดจาก release เดียวกัน แต่รอบนี้ไม่ได้ดาวน์โหลดหรือรัน binary จึงไม่ได้อ้างว่าได้ verify local file

ผมอ่าน security guidance เรื่อง sandbox/approval และตรวจหน้า official advisories ว่ามีประกาศที่กระทบรุ่นนี้หรือไม่ ณ เวลาตรวจ ไม่พบรายการ high/critical ที่ระบุว่า 0.158.0 ยังเปราะบางโดยไม่มี mitigation การตรวจนี้ไม่รวม private advisory, zero-day หรือ dependency ที่ยังไม่ถูกแจ้ง

default permission ที่เกี่ยวข้องยังต้องมาจาก configuration ของผู้ใช้และ environment ไม่ได้มีหลักฐานว่ารุ่นนี้ทำให้ filesystem, shell และ network ปลอดสิทธิ์โดยอัตโนมัติ Release บอกว่า approval สำหรับ terminal input ใน elevated command ถูกเปิดโดยปริยาย แต่ไม่ใช่ approval ทุกคำสั่ง

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

ค่าอัปเดตตัว CLI อาจเล็ก แต่ต้นทุน rollout อยู่ที่ regression test ของ policy, MCP และ shell การอัปเดตโดยไม่ทดสอบอาจทำให้งานหยุดเพราะ approval เพิ่ม หรือแย่กว่านั้นคือ config เดิมตีความต่าง ทีมควร canary กับ repository ที่ไม่ถือ secret ก่อน

ฟีเจอร์ image editing แบบ file-backed ลดการส่งภาพผ่าน memory บางเส้นทางและรองรับ transparency แต่เพิ่มไฟล์ชั่วคราว/ผลลัพธ์ที่ต้องจัด retention ถ้าภาพมีข้อมูลลูกค้า ต้องกำหนดที่เก็บ สิทธิ์ และการลบตามนโยบาย ไม่ใช่คิดว่าเป็นเพียง UI feature

MCP secret กับ bearer token ลด friction ใน automation ซึ่งอาจทำให้ทีมเชื่อม tool มากขึ้น จำนวน integration ที่มากขึ้นเพิ่มงาน inventory, rotation และ incident response ควรกำหนด owner ต่อ server และงบ token/compute แยกจาก permission budget

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

Release notes อธิบายว่าแก้อะไร แต่ไม่ได้ให้ threat model หรือ reproduction ของทุก sandbox fix ต่อสาธารณะ ซึ่งเหมาะกับบางประเด็นความปลอดภัยแต่ทำให้ประเมิน exploitability ราย environment ได้จำกัด เอกสาร security ให้หลักการทั่วไป ไม่ได้ยืนยันว่าการตั้งค่าองค์กรแต่ละแบบผ่าน regression แล้ว

ยังไม่ชัดว่าปัญหา nested writable roots ก่อนแก้ถูก trigger ได้ใน configuration แบบใดบ้างและมีการใช้โจมตีจริงหรือไม่ หน้า advisories ที่ตรวจไม่แสดง high/critical สำหรับรุ่นนี้ แต่ changelog fix ไม่จำเป็นต้องมี CVE ทุกตัว จึงไม่ควรสรุปว่าเป็น purely cosmetic

สิ่งที่แหล่งทางการพูดไม่ตรงระดับกันคือ release เน้นความสามารถและ fix รายรายการ ส่วน security docs เน้น shared-responsibility ว่าผู้ใช้ต้องกำหนด approval/sandbox เอง ทั้งสองไม่ได้ขัดกัน แต่หากอ่านเฉพาะ release อาจเผลอคิดว่าติดตั้งแล้ว policy ปลอดภัยครบ

ไม่มี checksum แบบเดียวสำหรับ package manager ทุกช่องทางในหลักฐานที่ตรวจ และไม่ได้ตรวจ notarization/signature ของ binary ทุก platform รอบนี้ ทีมที่ติดตั้งผ่าน npm/Homebrew/Windows package ควรใช้ provenance ของช่องทางนั้นเพิ่ม

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

ดาวน์โหลดจากช่องทาง official เท่านั้น pin version ใน environment ที่ต้อง reproducible และตรวจ digest/signature เมื่อช่องทางมีให้ อย่ารัน curl ต่อ shell หรือ remote installer ใน repository ที่มี credential สำคัญ แยก staging user และ workspace สำหรับ smoke test

ตั้ง sandbox เป็น workspace-write หรือ read-only ตามงาน ให้ network ปิดโดยปริยาย เปิดเฉพาะ domain ที่ต้องใช้ และอย่า mount home directory, SSH key, cloud config หรือ production secret เข้า session ทั้งก้อน Token ของ MCP/exec-server ควรสั้น มี scope แคบ เก็บใน secret store และไม่อยู่ใน prompt/log

กำหนด approval สำหรับคำสั่งเปลี่ยน state, network publish, package install, Git metadata และ action ที่ย้อนกลับไม่ได้ ทดสอบ paste หลายบรรทัด, symlink ออกนอก root, nested root, worktree .git file และ interrupted approval ใน repository ทดสอบ

บันทึก audit ว่าใครเริ่ม session, ใช้ model/tool ใด, policy version อะไร และ action ใดได้รับ approval แต่ทำ redaction secret ก่อนเก็บ log สร้าง kill switch ของ MCP server และ exec-server แยกจาก client เพื่อหยุดความเสียหายได้แม้ client ค้าง

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

Prompt injection ใน issue, เอกสาร, web page หรือ tool output ยังหลอก agent ได้ Sandbox ลดผลแต่ไม่เข้าใจ intent ธุรกิจ หาก tool มีสิทธิ์ส่งข้อความหรือแก้ cloud resource โดยตรง action ที่ schema ถูกต้องอาจยังผิดคนหรือผิด environment

Zero-day ใน CLI, dependency, OS sandbox หรือ MCP server ยังเป็นไปได้ และหน้า advisory สาธารณะมี lag ได้ Artifact digest ยืนยันความตรงของไฟล์กับ release metadata แต่ไม่ยืนยันว่า source ไม่มี bug หรือ publisher account ไม่ถูกยึด

มนุษย์อาจกดอนุมัติเพราะข้อความยาวหรือรีบ งานออกแบบ approval ต้องแสดง command, cwd, network destination และผลกระทบอย่างอ่านง่าย ไม่ควรพึ่ง modal “Allow” ทั่วไป การใช้ permission กว้างถาวรเพื่อลดความรำคาญทำลายประโยชน์ของ gate

ควรทำอะไร

ผู้ใช้เดี่ยวควรอัปเดตใน workspace ทดลอง ตรวจ version และ config diff แล้วลอง read/write, shell approval, Git operation และ MCP auth ก่อนนำกลับงานจริง สำรอง config แต่ไม่คัดลอก token ไปไฟล์ที่ commit

ทีม platform ควรทำ policy-as-code regression บน Windows, Linux และ macOS ที่ใช้จริง รวม path แปลก, symlink, nested worktree, credential boundary และ network egress บังคับ canary และ rollback เวอร์ชันได้

ทีม security ควรตรวจ MCP server inventory, token scope, websocket TLS/origin/authentication และ retention ของ file-backed images เพิ่ม use case ใน threat model แทนการตรวจเฉพาะตัว CLI

ทีมที่ยังอยู่ 0.156.x หรือต่ำกว่าไม่ควรข้ามอ่าน intermediate release note เพราะ behavior อาจสะสมหลายรุ่น แต่สามารถอัปตรงหลัง regression ได้โดยไม่ต้องรัน binary ทุกเวอร์ชันระหว่างทาง

Recap

• provenance, tag และ digest ของ 0.158.0 ตรวจย้อนกลับได้
• รุ่นนี้แก้ sandbox/metadata หลายจุดและเพิ่ม credential path ใหม่
• ผลคือผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ ไม่ใช่คำรับรองถาวร
• pin version และตรวจ artifact ตามช่องทางที่ติดตั้ง
• ใช้ least privilege, egress allowlist, short-lived token และ approval
• ทดสอบ nested roots, symlink, Git metadata, MCP และ exec-server ก่อน rollout