Qwen Code 0.25.1 อุดช่อง permission หลายจุด แต่ default ยังต้องล็อกก่อนใช้กับ repo จริง

Qwen Code 0.25.1 เป็นรุ่น stable วันที่ 11 ตุลาคม 2026 ที่แก้จุดเสี่ยงซึ่งทำให้ผมไม่รับรุ่น 0.25.0 ในรอบก่อน ได้แก่ workspace setting ที่เคยเปลี่ยนเพดาน memory agent, กฎ MCP ที่อาจชนชื่อข้าม server, การ parse tool call ซึ่งซ่อนอยู่ใน parameter และการหยุด process group ของ background shell ครับ รุ่นใหม่นี้จึง ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ 2026-10-12 แต่ไม่ได้แปลว่าปลอดภัยแน่นอนหรือควรรันด้วยสิทธิ์ผู้ใช้เต็มทันที

ผมตรวจแบบอ่านอย่างเดียวจาก release ทางการ, metadata บน npm, เอกสาร trust/sandbox และ advisory ของ repository ไม่ได้รัน installer, package, binary, extension หรือ MCP ใดกับ repository นี้ จุดสำคัญคือ 0.25.1 เพิ่ม surface ของ managed agent, background shell, child session และ automation ไปพร้อมกับแก้ boundary หลายจุด การอัปเดตจึงต้องถือเป็น migration ด้านสิทธิ์ ไม่ใช่ patch UI ธรรมดา

สรุป 30 วินาที

• release tag v0.25.1 ชี้ commit ทางการและมี release assets สำหรับ macOS, Linux และ Windows พร้อม SHA256SUMS
• npm package ระบุ version 0.25.1, repository เดียวกัน, integrity sha512-6cEbtfx4Ugl1d3FdFLa8fcsG6knHuUUHqvDseLxGY06Xan8p7Fcd7+g5KlX694zX4mo/+Vh56AHxT/4R15zpYA==, registry signatures และ SLSA provenance attestation
• release แก้ให้ memory-agent budget รับค่าจาก user/system scope และเพิกเฉย workspace scope ซึ่งลดโอกาส repo ที่ clone มาถอด turn/time cap
• release แก้ MCP permission collision, revalidate input ที่ hook แก้, escape control character ใน approval preview และหยุด destructive command ที่ถูกปฏิเสธซ้ำเพื่อขอ manual approval
• แต่ Trusted Folders ยังต้องเปิดเองตามเอกสาร และ approval mode ค่า default เป็น auto ซึ่งอาศัย classifier แยก action ปลอดภัย
• Linux tool-execution sandbox มี workspace-write/read-only และ network closed/open แต่ host reads ยังไม่ใช่ secret isolation สมบูรณ์ ส่วน qwen serve และ integration บางแบบไม่รองรับ boundary เดียวกัน
• คำแนะนำเริ่มต้นคือ pin version, ตรวจ checksum, ใช้ workspace แยก, เปิด trust check, เลือก approval default, ปิด network หากไม่ต้องใช้ และไม่ส่ง ambient credentials เข้า process

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

coding agent ต่างจาก autocomplete เพราะมันอ่านไฟล์ แก้โค้ด รัน shell ต่อ network และเรียก MCP ได้ ถ้า repository มี instruction หรือ config ที่ไม่น่าไว้ใจ agent อาจได้คำสั่งจากสิ่งที่เราเพิ่ง clone มา เหมือนรับช่างเข้าบ้านพร้อมพวงกุญแจทุกห้อง ต่อให้ช่างเก่งก็ต้องเลือกว่าประตูไหนเปิดได้และต้องถามก่อนทำอะไร

0.25.1 น่าสนใจเพราะแก้ boundary ที่สัมพันธ์กับโจมตีจาก workspace โดยตรง รุ่นก่อนมี issue ว่า setting ใน workspace เปลี่ยนเพดาน agent ที่ auto-approved ได้ รุ่นนี้ย้าย authority ไปที่ trusted operator scopes และเตือนเมื่อ workspace พยายามกำหนดค่า นอกจากนี้การกัน MCP rule ชนกันสำคัญมาก เพราะชื่อ tool เหมือนกันไม่ได้แปลว่ามาจาก server เดียวกัน

ในอีกด้าน release เพิ่ม managed-agent features มาก เช่น background Shell/Monitor, child sessions, team records, schedule/automation records และการเปลี่ยน working directory แบบ durable ฟีเจอร์เหล่านี้เหมาะกับงานยาว แต่เพิ่ม state ที่ต้องกู้คืนและสิทธิ์ที่ทำงานต่อหลังหน้าจอเดิมหาย ทีมที่อัปเดตเพราะต้องการ bug fix จึงควรตรวจว่าฟีเจอร์ใหม่ใดถูกเปิดจริงและ policy เดิมครอบคลุมหรือไม่

มันทำงานยังไง: trust, approval และ sandbox เป็นคนละชั้น

Trusted Folder ตัดสินว่าจะโหลด workspace settings, .env, extension และ auto-accept rule จากโปรเจกต์หรือไม่ เอกสารทางการ ระบุว่าฟีเจอร์นี้ปิดเป็นค่าเริ่มต้น เมื่อเปิดแล้ว folder ที่ยังไม่ไว้ใจจะเข้า safe mode และไม่โหลด config อันตรายบางชนิด นี่เป็นด่านตรวจบัตรหน้าตึก แต่ต้องเปิดด่านก่อนจึงจะมีผล

Approval mode ตัดสินว่า tool call ต้องถามคนหรืออนุมัติอัตโนมัติ เอกสาร settings ระบุ plan, default, auto-edit, auto และ yolo; ค่า default คือ auto ซึ่งใช้ classifier อนุมัติสิ่งที่เห็นว่าปลอดภัย ถ้างานแตะ production, secret หรือ repository ใหม่ ควรใช้ default หรือ plan จนเข้าใจ flow อย่าใช้ yolo เพื่อแก้ความรำคาญ เพราะมันเปลี่ยนความไม่แน่ใจให้เป็นสิทธิ์ทันที

Sandbox ตัดสินขอบ filesystem/network ของ command หลังได้รับอนุมัติ เอกสาร sandbox ของรุ่น 0.25.1 ระบุ Linux boundary ที่เลือก read-only หรือ workspace-write และปิด network ได้ โดย bwrap เป็นตัวเลือกแข็งแรงกว่า แต่ยังอ่าน path บน host ได้กว้างและไม่ควรถือว่าแยก secret สมบูรณ์ Approval กับ sandbox จึงทำคนละงาน: คนหนึ่งตอบว่า “อนุญาตคำสั่งนี้ไหม” อีกคนตอบว่า “ถึงอนุญาตแล้ว คำสั่งไปได้ไกลแค่ไหน”

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

Publisher และ repository ตรงกันระหว่าง npm กับ QwenLM/qwen-code release tag v0.25.1 เผยแพร่ 11 ตุลาคม 2026 และ tag ชี้ commit c1a8218f38203e272e6e965778ed6a2795cfeed7 Release assets มี digest SHA-256 รายไฟล์และไฟล์ SHA256SUMS; ตัวอย่าง asset macOS arm64 มี digest 09c3968cb9fce416765ad4fb5463c01add5798d82b3604b99b8a11aebf304807 ส่วน npm มี shasum 5eb56cf0240abde4d7ac55cad83005883e43dcbb นอกเหนือจาก integrity แบบ SHA-512

หน้า security advisories ของ repository ไม่แสดง advisory ที่ประกาศสาธารณะ ณ เวลาตรวจ แต่การไม่มีรายการไม่ใช่หลักฐานว่าไม่มี zero-day ผมจึงอ่าน changelog และ issues ที่รุ่นก่อนติดค้างเพิ่ม 0.25.1 ระบุ fix เรื่อง memory scope, MCP permission collision, XML tool call ใน parameter, control character ของ approval card, destructive-command denial, worker path containment และ process-group shutdown โดยตรง

เส้นทางติดตั้งที่แนะนำในเอกสารมี hosted shell/PowerShell installer ซึ่งดึง “latest” ได้ แต่ผมไม่ได้รันและไม่แนะนำให้ pipe เข้า shell สำหรับ environment สำคัญ ทางที่ตรวจซ้ำง่ายกว่าคือดาวน์โหลด asset ของ version ที่ pin จาก release ทางการ ตรวจ SHA256SUMS และรันใน identity ที่ไม่มี credential เกินจำเป็น หรือใช้ package manager lock ที่บันทึก integrity

Default permissions ยังไม่แคบที่สุด: folder trust ปิดโดยค่าเริ่มต้นและ approval auto อาจอนุมัติ action ตาม classifier เอกสารอธิบายความเสี่ยงของ yolo, sandbox และ qwen serve อย่างเปิดเผย จึงไม่เข้ากรณีให้สิทธิ์กว้างโดยไม่เตือน แต่ผู้ดูแลต้องลงมือเปลี่ยนค่าเองก่อนใช้งานกับ code ที่ไม่ไว้ใจ

เงินและผลกระทบต่อการอัปเดต

รุ่นนี้ไม่ได้ประกาศราคาใหม่ใน release notes ต้นทุนหลักคือเวลา migration และการแยก environment ทีมต้องตรวจ settings hierarchy, trust database, hooks, extensions, MCP servers, background processes และ log retention ถ้าใช้ managed session การเพิ่ม durable records ช่วย audit แต่ก็เพิ่มข้อมูลที่ต้องกำหนด retention และ access control

การ pin version ลดความเสี่ยงจาก hosted installer ที่เลื่อน latest แต่เพิ่มภาระติดตาม patch ทีมควรกำหนดรอบอัปเดตพร้อม checklist ไม่ใช่ปล่อย workstation แต่ละเครื่องต่างเวอร์ชัน เพราะ incident หนึ่งครั้งอาจ reproduce ไม่ได้หาก CLI, model และ plugin เปลี่ยนพร้อมกัน

อะไรยังไม่ชัด และแหล่งข่าวไม่ตรงกันตรงไหน

release notes ยาวมากและรวม CLI, mobile, Web Shell, hosted runtime, SDK และ CI ใน tag เดียว จึงยังไม่ชัดว่า npm package path ที่ผู้ใช้ทั่วไปติดตั้งพกทุก component หรือเปิด feature ใดเป็นค่าเริ่มต้นบ้าง การมีโค้ดใน repository ไม่เท่ากับเปิดใช้บนเครื่องทุกคน ต้องตรวจ effective config ด้วยคำสั่ง diagnostic ของรุ่นที่ติดตั้งใน environment ทดสอบ

npm provenance ยืนยันเส้นทาง build/publish ตาม attestation ที่ registry แสดง แต่ไม่ได้รับรอง behavior ของ runtime ส่วน SHA256SUMS ยืนยันไฟล์ไม่เปลี่ยนจาก release ที่ publisher วางไว้ แต่ไม่ได้พิสูจน์ว่า publisher ไม่มี bug ทั้งสองอย่างแก้ supply-chain question คนละชั้นกับ permission design

เอกสาร sandbox บอกชัดว่า host reads ยังกว้าง, Landlock เป็น partial enforcement และ integration บางแบบไม่รองรับ tool-execution sandbox เดียวกัน จึงไม่ควรสรุปว่าเปิด workspace-write แล้ว secret ใน home directory ปลอดภัยทั้งหมด นอกจากนี้ advisory index อาจตามหลัง bug ที่ยังไม่เปิดเผย

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

เริ่มจากเครื่องหรือ container ทดสอบที่ไม่มี credential จริง สร้าง workspace เฉพาะงานและ mount เท่าที่ต้องใช้ เปิด folder trust แล้วเลือก “ไม่ไว้ใจ” สำหรับ repo ใหม่จน review .qwen, instruction, hooks และ extension manifest ครบ ตั้ง approval เป็น default หรือ plan; หลีกเลี่ยง auto, auto-edit และ yolo ในช่วงสำรวจ

บน Linux ให้กำหนด tools.executionSandbox ที่ system/user scope ไม่ใช่ workspace ใช้ filesystem: "workspace-write" หรือ read-only และ network: "closed" เมื่อไม่ต้องดาวน์โหลด จากนั้นตรวจ effective boundary ด้วยคำสั่ง verify ของ sandbox ก่อนให้ agent ทำงาน อย่าส่ง SSH_AUTH_SOCK, cloud token, package registry token หรือไฟล์ credential เข้า process ถ้าไม่จำเป็น

MCP และ extension ทุกตัวต้องมี owner, version pin, tool allowlist และการทบทวนตอน update อย่าใช้ trust: true แบบกว้างเพียงเพราะ server อยู่ในเครื่องเดียวกัน แยก read-only tool จาก mutation tool และเก็บ human approval สำหรับ shell, write, network และการเปลี่ยน working directory

ดาวน์โหลด release แบบระบุ versionจาก GitHub ทางการ ตรวจ checksum และ provenance ก่อนติดตั้ง ไม่ใช้ remote installer แบบ pipe-to-shell ใน production ห้ามทดลอง agent ใหม่นี้กับ repository จริง, production network หรือ credential ก่อนผ่าน dry run ด้วย fixture ที่ไม่มีข้อมูลลับ

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

prompt injection ยังทำให้ model ขอ action ที่ดูสมเหตุผลแต่ไม่ตรงเจตนา classifier อาจตัดสินผิด ผู้ใช้อาจกดอนุมัติโดยไม่อ่าน และ tool ที่ได้รับอนุญาตอาจมี bug เอง Background process กับ durable session เพิ่มความเสี่ยงเรื่องงานทำต่อหลังผู้ใช้คิดว่าหยุดแล้ว แม้รุ่นนี้เพิ่ม process-group และ cancellation fixes

workspace-write ไม่ป้องกันทุก read และ network-open เปิดทาง exfiltration หาก process เห็น secret การปิด network ก็ไม่ช่วยเมื่อ tool เชื่อม host service หรือ MCP ที่มีสิทธิ์กว้าง ขอบเขตต้องเริ่มจาก OS identity, container/VM และ credential separation ไม่ใช่ตั้งค่า CLI อย่างเดียว

สุดท้าย รายการ advisory ว่างและ release provenance ดีเป็นหลักฐาน ณ เวลาเดียว ไม่ใช่คำรับรองอนาคต ต้องติดตาม issue, advisory และ patch ต่อ รวมทั้ง retest เมื่อ model, policy หรือ plugin เปลี่ยน บทความนี้จึงสรุปเพียงว่า Qwen Code 0.25.1 ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ ภายใต้การ pin, sandbox และ permission hardening ที่อธิบายไว้

ควรทำอะไร

ผู้ใช้เดี่ยวควรอัปเดตใน workspace ทดลองก่อน เก็บ config เดิม เปรียบ effective permission และทดสอบ cancel/background process โดยไม่มีข้อมูลจริง ทีมองค์กรควรทำ golden config ที่ user ลดข้อจำกัดไม่ได้ บังคับ checksum/provenance และบันทึก tool approvals เพื่อ audit

ถ้ายังใช้ 0.25.0 เพราะต้องการรอ ให้ปิด memory agent/managed features ที่ไม่จำเป็นและอย่าให้ workspace กำหนด limit เอง แต่ทางเลือกที่ดีกว่าคือทดสอบ 0.25.1 แล้วอัปเดตเมื่อ gate ภายในผ่าน หาก environment รองรับ sandbox ไม่ครบ ให้ใช้ VM/container ที่แยก identity หรือหยุดใช้ tool กับข้อมูลลับแทนการอ้างว่า approval prompt พอแล้ว

Recap checklist

• pin v0.25.1 และตรวจ npm integrity หรือ release SHA-256
• เปิด Trusted Folders และไม่ trust repo ก่อน review config/instructions
• ใช้ approval default หรือ plan ในงานเสี่ยง
• บังคับ sandbox จาก operator scope และปิด network เมื่อไม่จำเป็น
• แยก ambient credentials ออกจาก agent process
• review MCP, hook, extension, subagent และ background session แยกกัน
• ติดตาม advisory/issues ต่อ เพราะผลคัดกรองมีอายุ
• สื่อสารว่า “ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ” ไม่ใช่ “ปลอดภัยแน่นอน”