Claude Code 2.1.295 เพิ่ม onFailure block: hook ล้มแล้วหยุด action แทนปล่อยผ่าน

Anthropic ออก Claude Code 2.1.295 วันที่ 8 ตุลาคม 2026 จุดเด่นด้าน policy คือเพิ่ม onFailure: "block" ให้ command hooks และ HTTP hooks: ถ้า hook เริ่มไม่ได้, timeout หรือจบด้วย exit code ที่ไม่คาด action จะถูกบล็อกแทนที่จะปล่อยผ่านครับ นี่คือ fail-closed—ด่านตรวจเสียแล้วปิดประตู—ซึ่งเหมาะกับ hook ที่มีหน้าที่บังคับ policy มากกว่า hook ที่ใช้แค่แจ้งเตือน

ผมตรวจ repository/tag/changelog, metadata ของ npm 2.1.295, SHA-256/ไฟล์ SHASUMS256 และ signature ของ release assets, เอกสาร security และ public advisories แบบอ่านอย่างเดียว ไม่ได้ติดตั้ง package, รัน binary, เรียก installer หรือเชื่อม MCP ด้วย credential รุ่นนี้ ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ 2026-10-09 เมื่อ pin artifact และใช้ block เฉพาะ hook ที่ออกแบบให้ reliable พร้อม recovery path

สรุป 30 วินาที

• onFailure: "block" ทำให้ command/HTTP hook ที่ start ไม่ได้, timeout หรือ exit ผิดหยุด action แทน fail-open
• รุ่นนี้ยังเตือนเมื่อคำสั่ง install/enable/disable plugin หรือเพิ่ม marketplace เขียน settings file ที่จริงไม่ได้ถูกโหลด ลด false sense of success
• gateway เพิ่ม upstream time-to-first-byte timeout, model allowlist ต่อ upstream และ request id สำหรับ audit/failover
• remote MCP reconnect มี backoff และแก้ pagination cursor วนซ้ำ รวมถึงแก้ deny rule ของ Claude in Chrome ที่ระบุพอร์ต 80
• npm integrity ที่ตรวจคือ sha512-PTdE5NdqwwyCmtbX/0WAuosyip8DkwC6M5mAJv+b9KGuxMFnkTJbc2b3EY6FYdo5ZTWkm6MN8reA9YWWMrLR+g==; release assets มี SHA-256 และ signature แยก ต้องตรวจไฟล์จริงตาม platform
• advisory ระดับสูงล่าสุดที่ตรวจมี affected range ก่อน 2.1.129; 2.1.295 อยู่นอกช่วงประกาศ แต่ plugin/hook/MCP และ dependency ต้องตรวจแยก

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

หลายทีมใช้ hook ตรวจคำสั่ง, ป้องกันไฟล์ลับ, บังคับ ticket หรือแจ้งระบบ audit หาก hook มีปัญหาแล้ว agent ยังเดินต่อ นโยบายที่ดูเหมือนเปิดใช้อยู่จะหายไปเงียบ ๆ เปรียบเหมือนประตูโรงงานที่เซ็นเซอร์ดับแล้วเปิดค้างเพื่อไม่ให้สายพานหยุด เหมาะกับระบบที่ availability สำคัญ แต่ไม่เหมาะกับด่านห้าม publish secret

การเลือก fail-closed จึงเปลี่ยน outage ของ hook เป็น outage ของ action โดยตั้งใจ ช่วยไม่ให้ “ระบบตรวจล่ม” กลายเป็น bypass แต่สร้างความเสี่ยงอีกด้าน: HTTP service ปลายทางช้า หรือ script มี dependency หาย งานทุกคนอาจถูกบล็อก ต้องออกแบบ timeout, retry, redundancy และ break-glass ที่ตรวจสอบได้ ไม่ใช่เปิด block แล้วคิดว่างานจบ

ฟีเจอร์เตือน settings ไม่โหลดก็สำคัญ เพราะ plugin/marketplace เพิ่ม code และ tool surface การที่ CLI บอก “เขียนไฟล์แล้ว” แต่ runtime ไม่อ่านไฟล์นั้นทำให้ผู้ใช้เชื่อว่าปิด plugin แล้วทั้งที่ session ยังมีของเดิม หรือเชื่อว่า policy ใหม่ทำงานทั้งที่ไม่เคยโหลด Warning ทำให้เห็น configuration drift แต่ผู้ดูแลยังต้องยืนยัน effective state

ทำงานยังไง: ด่านตรวจสามผลลัพธ์

Hook แบบ policy มีอย่างน้อยสามสถานะ: allow, explicit deny และ infrastructure failure ก่อนรุ่นนี้ failure บางแบบอาจปล่อย action ผ่านเพื่อรักษางาน รุ่น 2.1.295 ให้เลือก onFailure: "block" เพื่อ map สถานะที่สามไป deny ชั่วคราว ผู้ใช้จึงเห็นว่าด่านเสียและ action ไม่ถูกเรียก

ความแตกต่างระหว่าง explicit deny กับ hook failure ต้องถูกเก็บใน audit log เพราะวิธีแก้ไม่เหมือนกัน Deny หมายถึง policy ตัดสินจาก input ส่วน failure หมายถึง process/HTTP/timeout/config มีปัญหา อย่าตอบข้อความเดียวว่า “ไม่อนุญาต” จนทีมไปเปลี่ยน policy ทั้งที่ DNS ล่ม และอย่าใส่ secret/body เต็มใน error เพื่อช่วย debug

Command hook รัน process บนเครื่อง จึงรับ inheritance ของ filesystem, environment, PATH และ user permissions หาก hook script อยู่ใน repository ที่ agent แก้ได้ มันไม่ใช่ trust anchor ผู้โจมตีผ่าน prompt injection อาจแก้ด่านก่อนขอ action ต้องวาง policy hook ใน path read-only/managed, pin interpreter และ dependency, ใช้ absolute executable path และ sanitize input

HTTP hook เพิ่ม network, TLS, DNS, authentication และ service availability เป็น dependency ต้อง allowlist endpoint, pin/ตรวจ TLS ตามนโยบาย, ใช้ credential อายุสั้น scope เฉพาะการตัดสิน, จำกัด request/response size และกำหนด behavior เมื่อ response schema ผิด onFailure: block ช่วยผลลัพธ์ปลอดภัยกว่า แต่ไม่ได้ป้องกันปลายทางที่ถูกยึดแล้วตอบ allow

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

GitHub release เป็น immutable release tag v2.1.295 ใน repository ทางการและระบุ change list ชัดเจน Publisher มี npm package ทางการ พร้อม registry integrity ข้างต้น Release assets แสดง SHA-256, SHASUMS256 และ .sig ตามรายการที่ตรวจ จึงมีทางตรวจ byte และ signature แต่ผู้ติดตั้งต้องตรวจคู่ไฟล์ของ platform จริง ไม่คัดค่า asset หนึ่งไปอ้างอีก asset

Release note ยังระบุ model allowlist ต่อ upstream, TTFB timeout, gateway audit request id, remote MCP reconnect backoff และ warning settings file สิ่งเหล่านี้เกี่ยวกับ availability/audit มากกว่าการลดสิทธิ์โดยตรง ต้องไม่เขียนเกินว่า 2.1.295 “ทำ MCP ปลอดภัย” ทั้งระบบ

Public advisories ที่ตรวจมีรายการเก่าหลายรายการ; advisory high ที่ใหม่สุดในชุดตรวจมี fixed version 2.1.129 และ 2.1.295 อยู่นอก affected range ที่ประกาศ ณ วันตรวจ การไม่พบ advisory ที่กระทบรุ่นนี้ไม่พิสูจน์ absence ของช่องโหว่ และ marketplace/plugin อาจมี code คนละ repository ที่ไม่อยู่ในหน้าเดียวกัน

Install path ถูกอ่านจาก release/npm metadata โดยไม่รัน package, postinstall, binary หรือ remote script ไม่มีการให้ tool เข้าถึง repository จริง, production, private network หรือ credential ระหว่างคัดกรอง Dependency risk จึงประเมินจาก provenance/advisory สาธารณะ ไม่ใช่ dynamic analysis

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

Fail-closed ลดต้นทุน incident จาก policy bypass แต่เพิ่มต้นทุน downtime เมื่อ hook service ไม่พร้อม ทีมต้องตั้ง SLO ของ policy service, cache decision ที่ปลอดภัยเฉพาะกรณี, health check และ capacity planning หากทุก shell call ต้อง round-trip ไป HTTP hook latency จะสะสมกับงาน agent และอาจกระตุ้นให้ผู้ใช้หาทาง bypass

Gateway TTFB timeout ช่วยไม่ให้ request ค้างก่อน stream เริ่ม แต่ failover ไป upstream อื่นมี data-residency และ cost implication Model allowlist ต่อ upstream ลดโอกาสส่งโมเดลผิดปลายทาง แต่ต้องทดสอบ wildcard และ default หาก config หาย Audit request id ช่วย trace ค่าใช้จ่าย/incidentเมื่อเก็บ mapping ครบ

Plugin settings warning ลดเวลาหา configuration drift แต่ไม่แทน inventory หรือ approved marketplace องค์กรควรมีรายการ plugin, publisher, version, permission, owner และวัน review เพราะ plugin update เปลี่ยน code ที่รันบนเครื่องได้

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

Release note บอก failure classes หลักที่ block แต่ไม่ได้ระบุ semantics ทุก edge case เช่น retry จำนวนเท่าใด, partial HTTP response, signal, process child ค้าง หรือหลาย hook ต่อกันในข้อความสรุป ทีมต้องอ้าง docs/config schema รุ่นเดียวกันและสร้าง failure-injection test ก่อนถือเป็น control

คำว่า immutable release หมายถึง asset/tag release มี protection ตาม GitHub ไม่ได้แปลว่า dependency graph หรือบริการ remote immutable npm integrity กับ GitHub SHA เป็นคนละ provenance chain ต้องเลือกตาม install method และห้ามเปรียบเทียบข้าม artifact

Security docs อธิบาย permission model โดยรวม ส่วน release note อธิบาย featureเฉพาะ ไม่มีหลักฐานจากสองแหล่งว่าค่า default ของ hook ทุกชนิดเปลี่ยนเป็น block ผู้ใช้ต้องตั้ง onFailure อย่างชัดเจนใน hook ที่ต้องการ อย่าเดาจากชื่อเวอร์ชัน

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

1. pin 2.1.295 และตรวจ npm integrity หรือ SHA/signature ของ binary ที่ติดตั้งจริง
2. จัดประเภท hook: security enforcement ใช้ block; telemetry/notification อาจไม่ควรหยุดงาน แต่ต้องรายงาน failure
3. วาง command hook/script ใน managed read-only path ใช้ absolute path, minimal environment และไม่อ่าน config จาก workspace โดยไม่ validate
4. HTTP hook ใช้ allowlisted HTTPS endpoint, short-lived credential, schema/size limit, strict timeout และ audit request id
5. ทดสอบ start failure, timeout, unexpected exit, malformed response, network partition และ recovery ด้วย fixture ที่ไม่มี secret
6. สร้าง break-glass แบบ time-bound, require approver, แจ้งเตือน และ log; ห้ามมี bypass flag ถาวรใน shell profile
7. pin/allowlist plugin, marketplace และ MCP server ตรวจ provenance/advisory/permission แยก
8. จำกัด filesystem, shell, network และ secret ของ Claude Code ไม่ถือว่า hook อนุญาตแล้ว action ปลอดภัยทุกด้าน

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

ทีมเล็กควรเริ่มจาก hook ที่กัน action ย้อนกลับยาก เช่น publish/deploy/secret-bearing command เปิด block ใน canary แล้วจำลอง failure ก่อนใช้จริง ถ้าระบบหยุด ให้แก้ reliability หรือแบ่ง hook ไม่ควรย้อนกลับไป fail-open โดยไม่บันทึก risk acceptance

องค์กรควรใช้ managed settings บังคับ policy, monitor warning ว่า settings ไม่โหลด และตรวจ effective config จาก session จริง แยก team-owned hook service จาก repository code ตั้ง SLO/on-call และมี dashboard ของ allow/deny/failure/latency โดย redact payload

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

Hook ที่เขียนผิดอาจ allow คำสั่งอันตรายอย่างถูกต้องตามโปรแกรม Hook service อาจถูกยึด, credential รั่ว, DNS/TLS ถูกตั้งผิด หรือ policy ไม่มีข้อมูลพอ Prompt injection อาจโน้มน้าวคนให้ใช้ break-glass และ plugin/MCP ยังอ่านข้อมูลหรือเรียก network นอก hook ที่ตรวจ

Fail-closed ยังเปิดทาง denial of service: ผู้โจมตีหรือ outage ทำให้ hook fail แล้วหยุดงานทั้งหมด ต้อง rate-limit, isolate และวาง recovery โดยไม่ลด audit การผ่านเกณฑ์ครั้งนี้จึงไม่ใช่คำว่า “ปลอดภัยแน่นอน”; เป็นการยืนยัน publisher/version/provenance/advisory และ control ที่ต้องใช้ ณ วันที่ตรวจ

Recap

• pin 2.1.295 และตรวจ artifact ตามช่องทางจริง
• hook บังคับ policy ใช้ onFailure: block และแยกจาก hook แจ้งเตือน
• วาง trust anchor นอก workspace ที่ agent เขียนได้
• fault-inject start/timeout/exit/network/schema ก่อน rollout
• break-glass ต้องมีเวลา, approver และ audit
• ตรวจ plugin/MCP/gateway แยกและจำกัด secret/network
• บันทึก residual risk; รุ่นนี้ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ

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