Claude Code 2.1.307 เพิ่มบันทึกจุดหยุด AI แก้เรียกเครื่องมือซ้ำเมื่อสายหลุด

Claude Code 2.1.307 แก้ปัญหาที่การเรียกเครื่องมือผ่านเครือข่ายถูกส่งถึง 2 ครั้งเมื่อการเชื่อมต่อปิดกลางคัน โดยหลังแก้จะลองส่งซ้ำเฉพาะเครื่องมือที่อ่านข้อมูลอย่างเดียว หรือเรียกซ้ำแล้วไม่ทำให้ผลเพิ่มขึ้น นี่เป็นรายการแก้ไขที่ผู้พัฒนาระบุไว้ในรุ่นนี้ครับ (GitHub)

สำหรับคนที่ให้ AI ช่วยทำงาน ความต่างระหว่าง “อ่านข้อมูลอีกครั้ง” กับ “ทำรายการอีกครั้ง” สำคัญกว่าหน้าตาปุ่มใหม่มาก ผมอยากชวนมองอัปเดตนี้ผ่านเรื่องง่าย ๆ คือเราจะรู้ได้อย่างไรว่า AI ถูกหยุดตรงไหน คนอนุมัติอะไรไป และเมื่อระบบสะดุด งานที่มีผลต่อข้อมูลจะถูกทำซ้ำหรือเปล่า ประเด็นเหล่านี้เกี่ยวกับทั้งเวลาตรวจงานและความมั่นใจของคนที่ต้องรับผิดชอบงานสุดท้าย

สรุป 30 วินาที: เกิดอะไรขึ้น

รุ่นนี้เพิ่ม claude_code.safety_event ซึ่งเป็นเหตุการณ์สำหรับ OpenTelemetry หรือระบบส่งบันทึกการทำงานไปให้ทีมดูแลดูรวมศูนย์ บันทึกใหม่นี้ครอบคลุมการเรียกเครื่องมือแต่ละครั้งที่ถูกกฎสิทธิ์ โหมดอัตโนมัติ การตรวจความปลอดภัย ชุดคำสั่งประกอบการทำงาน หรือพื้นที่จำกัดการทำงาน สั่งหยุด ให้ถามอนุญาต หรือส่งกลับไปจัดการใหม่ (GitHub)

อีกจุดคือเมนู /permissions ส่วน Recently denied ซึ่งรวมสิ่งที่เพิ่งถูกปฏิเสธ จะแสดงคำสั่งเชลล์ หรือคำสั่งที่สั่งให้คอมพิวเตอร์ทำงานโดยตรง ที่ถูกปฏิเสธด้วย เมื่ออนุมัติจากตรงนี้ ตัวประเมินในโหมดอัตโนมัติจะนำการอนุมัตินั้นไปใช้ตอนตรวจคำสั่งที่ลองใหม่ และแถวอนุมัติจะระบุชื่อคำสั่งแทนคำบรรยาย (GitHub)

ส่วนงานเบื้องหลังที่ทีมดูแลระบบควรอ่าน มีทั้งการจำกัดเวลาชุดคำสั่งเตรียมงานบนเครื่องรันที่องค์กรดูแลเอง และข้อความเตือนเมื่อใช้โควตาค้นเว็บหมด ซึ่งเพิ่มคำบอก AI ว่าอย่าไปค้นผ่านเบราว์เซอร์หรือการควบคุมคอมพิวเตอร์ต่อ ทั้งสองเรื่องอยู่ในบันทึกการเปลี่ยนแปลงวันที่ 21 ตุลาคม 2026 (Claude Code Docs)

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

ถ้าคุณเป็นพนักงานออฟฟิศ เจ้าของร้าน ผู้ปกครอง หรือนักศึกษาที่ให้คนในทีมใช้ AI ช่วยทำระบบ ประเด็นที่ควรถามคือ AI มีสิทธิ์ทำอะไรกับงานนั้นบ้าง ผมแนะนำให้เริ่มจากแยกงานอ่านข้อมูลกับงานเปลี่ยนข้อมูล เพราะรายการแก้ไขเรื่องส่งซ้ำของรุ่นนี้แยกเครื่องมือสองลักษณะนี้ไว้ชัดเจน โดยอนุญาตการลองใหม่เฉพาะงานอ่านอย่างเดียวหรือทำซ้ำแล้วผลไม่เพิ่ม (GitHub)

คนที่ไม่ได้เขียนโค้ดเองก็ใช้ประเด็นนี้คุยกับผู้รับผิดชอบระบบได้ เช่น ก่อนเปิดให้ผู้ช่วย AI ทำงานจริง ขอให้ทีมสาธิตว่างานแบบไหนต้องมีคนอนุมัติ และถ้างานถูกปฏิเสธจะกลับไปดูอะไรได้บ้าง ผมเสนอให้ใช้หน้ารายการที่เพิ่งถูกปฏิเสธเป็นส่วนหนึ่งของการสาธิต เพราะรุ่นนี้แก้ให้เห็นคำสั่งที่ถูกปฏิเสธและให้โหมดอัตโนมัติรับรู้การอนุมัติจากหน้านั้นแล้ว (GitHub)

สำหรับทีมไอที ประโยชน์ที่ควรทดลองคือเชื่อมเหตุการณ์ความปลอดภัยเข้ากับการตรวจงานประจำวัน แทนที่จะรู้แค่ว่างานไม่ผ่าน ให้ตรวจว่ามีการหยุดหรือขออนุญาตระหว่างทางหรือไม่ อย่างไรก็ตาม แหล่งข่าวระบุเพียงว่ามีเหตุการณ์ใหม่ ยังไม่ได้ให้รายละเอียดข้อมูลทุกช่องหรืออธิบายการตั้งค่าระบบรับบันทึกครบถ้วนในข้อความที่มี จึงควรตรวจผลที่ได้รับจริงก่อนนำไปเป็นเงื่อนไขแจ้งเตือน (GitHub)

ทำงานยังไง

MCP คือช่องทางให้ AI เรียกใช้เครื่องมือหรือบริการที่เชื่อมไว้ ส่วน HTTP คือวิธีรับส่งคำขอผ่านเครือข่ายที่กล่าวถึงในรายการแก้ไข ปัญหาของรุ่นก่อนตามคำอธิบายผู้พัฒนาคือ เมื่อการเชื่อมต่อปิดระหว่างเรียกเครื่องมือ คำขออาจถูกส่งสองครั้ง รุ่นนี้จึงจำกัดชนิดเครื่องมือที่ลองส่งใหม่ได้ (GitHub)

คำสำคัญคือ idempotent หมายถึงกดซ้ำแล้วผลไม่เพิ่ม เช่น การดูยอดซ้ำยังเป็นการอ่าน ส่วนการโอนเงินซ้ำอาจเกิดรายการเพิ่ม ตัวอย่างนี้ใช้ช่วยแยกแนวคิดเท่านั้น ไม่ได้หมายความว่าแหล่งข่าวรายงานการโอนเงินซ้ำหรือระบุว่ามีเครื่องมือธนาคารอยู่ในเหตุการณ์นี้ กติกาที่ประกาศจริงคือจะลองซ้ำเฉพาะเครื่องมืออ่านอย่างเดียวหรือเครื่องมือที่ทำซ้ำแล้วผลไม่เพิ่ม (GitHub)

ลองนึกถึงร้านข้าวตามสั่งครับ ถ้าพนักงานไม่ได้ยินคำตอบ การถามว่า “ออร์เดอร์ถึงไหนแล้ว” ซ้ำยังเป็นการถาม แต่การส่งใบสั่งเพิ่มอีกใบอาจทำให้ได้ข้าวเพิ่มอีกจาน ประเด็นของการลองเรียกเครื่องมือใหม่ก็อยู่ที่ต้องแยกการถามซ้ำออกจากการสั่งทำเพิ่ม ระบบไม่ควรถือว่าทั้งสองอย่างเหมือนกันเพียงเพราะคำตอบหายไประหว่างทาง

ส่วนบันทึกความปลอดภัยทำหน้าที่ให้ข้อมูลว่าการเรียกเครื่องมือถูกแทรกแซงตรงไหน แหล่งข่าวระบุทั้ง permission rule หรือกฎอนุญาต, auto mode หรือโหมดให้ระบบประเมินการอนุมัติ, safety check หรือการตรวจความปลอดภัย, hook หรือชุดคำสั่งที่ผูกให้ทำงานตามจังหวะ และ sandbox หรือพื้นที่จำกัดขอบเขตการทำงาน แต่ไม่ได้กล่าวว่าเหตุการณ์ใหม่นี้เป็นตัวอนุมัติแทนคนหรือรับประกันว่าจะหยุดปัญหาได้ทุกแบบ (Claude Code Docs)

จึงควรแยกหน้าที่สองอย่างในใจ การควบคุมสิทธิ์เป็นเรื่องว่าจะให้ทำหรือไม่ ส่วนบันทึกเป็นข้อมูลให้ย้อนตรวจว่าเกิดอะไรขึ้น ผมแนะนำให้ทดสอบทั้งสองด้านร่วมกัน เพราะเห็นบันทึกครบแต่ตั้งสิทธิ์กว้างเกินไป ก็ยังไม่ตอบโจทย์การควบคุมงาน

จุดหักมุม: อนุมัติแล้ว ระบบต้องเข้าใจให้ตรงกันด้วย

รายการแก้ไขหน้าสิทธิ์สะท้อนปัญหาที่ละเอียดกว่าการมีปุ่มอนุมัติ ผู้พัฒนาระบุว่าตัวประเมินในโหมดอัตโนมัติเคยมองข้ามการอนุมัติจาก Recently denied เมื่อตรวจคำสั่งที่ลองใหม่ รุ่นนี้แก้ทั้งการแสดงคำสั่งที่ถูกปฏิเสธและการนำการอนุมัตินั้นมาใช้ (GitHub)

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

อีกจุดที่ควรอ่านให้ละเอียดคือเมื่อ WebSearch ใช้งบค้นหาหมด ข้อความที่ส่งให้ Claude จะเพิ่มคำสั่งไม่ให้ไปค้นผ่านเบราว์เซอร์หรือผ่าน computer use ซึ่งหมายถึงการให้ AI ควบคุมคอมพิวเตอร์ แหล่งข่าวอธิบายว่าเป็นการเปลี่ยนข้อความแจ้ง ไม่ได้บอกว่าเป็นการปิดทางออกสู่เครือข่ายทั้งหมดในระดับระบบ (Claude Code Docs)

ในมุมของผม ทีมที่ต้องจำกัดการใช้งานจึงควรทดสอบพฤติกรรมหลังโควตาหมดด้วย อย่าอ่านคำว่า “บอกไม่ให้ทำ” แล้วสรุปแทนว่าได้บังคับสิทธิ์ทุกทางเรียบร้อย รายละเอียดเล็กแบบนี้สำคัญเวลาเขียนกติกาให้คนใช้ร่วมกัน

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

แหล่งข่าวชุดนี้ไม่ได้ให้ราคาสำหรับผู้ใช้ไทย ค่าใช้จ่ายในการเก็บบันทึก หรือจำนวนเงินที่องค์กรจะประหยัดจากอัปเดตนี้ จึงยังคำนวณความคุ้มค่าเป็นเงินบาทไม่ได้ รายการที่ยืนยันได้คือการแก้ส่งคำขอเครื่องมือซ้ำและการเพิ่มเหตุการณ์ความปลอดภัย ส่วนผลต่อค่าใช้จ่ายจริงต้องวัดจากงานของแต่ละทีม (GitHub)

ผมแนะนำให้มองต้นทุนผ่านเวลาที่คนต้องตรวจและแก้งาน เช่น เวลาตามหาสาเหตุว่างานหยุดตรงไหน เวลาตรวจการอนุมัติ และเวลารอเตรียมสภาพแวดล้อม ก่อนอัปเดตให้บันทึกปัญหาที่เกิดอยู่ แล้วเปรียบเทียบหลังทดลอง วิธีนี้จะช่วยให้คุยเรื่องประโยชน์ได้จากงานจริง โดยไม่ต้องเดาตัวเลขผลประหยัด

สำหรับ self-hosted runner หรือเครื่องรันงานที่องค์กรดูแลเอง ชุดคำสั่งช่วงเตรียมสำเนาโครงการก่อนเริ่มงานจะถูกหยุดหลัง 30 นาทีโดยค่าเริ่มต้น และทำให้การเตรียมงานครั้งนั้นล้มเหลว ถ้าจำเป็นต้องใช้เวลานานกว่านี้ ผู้พัฒนาระบุว่าสามารถเพิ่มค่าจำกัดเวลา หรือกำหนดเป็น 0 ได้ (Claude Code Docs)

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

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

หน้า GitHub ของแท็ก v2.1.307 ระบุวันเผยแพร่เป็น 21 ตุลาคม 2026 และแสดงเวลา 22:17 แต่ข้อความต้นทางที่ให้มาไม่มีเขตเวลากำกับ ผมจึงใช้วันที่ตามแหล่งข่าวและไม่แปลงเวลานั้นเป็นเวลาไทย ส่วนหน้าประวัติการเปลี่ยนแปลงจัดรายการหลักของอัปเดตนี้ไว้ใต้วันที่ 21 ตุลาคมเช่นกัน จึงยังไม่เห็นความขัดแย้งเรื่องวันที่ในสองหน้านี้ (GitHub, Claude Code Docs)

หน้าประวัติยังมีหัวข้อวันที่ 22 ตุลาคม 2026 ซึ่งระบุเพียงการแก้ข้อผิดพลาดและเพิ่มความน่าเชื่อถือ ข้อความส่วนที่ให้มาไม่ได้จับคู่หัวข้อนี้กับเลขรุ่นอย่างชัดเจน จึงไม่ควรนำรายละเอียดทั้งหมดของวันที่ 21 ไปอ้างว่าเป็นรายการใหม่ของวันที่ 22 และเอกสารระบุเองว่าหน้านี้สร้างจากบันทึกการเปลี่ยนแปลงบน GitHub จึงไม่ใช่การทดสอบยืนยันจากคนละทีม (Claude Code Docs)

เรื่องผลกระทบก็ยังมีขอบเขตจำกัด รายการแก้ไขไม่ได้ระบุว่ามีองค์กรไทยได้รับผลกระทบ จำนวนคำขอที่เคยถูกส่งซ้ำ หรือความเสียหายที่เกิดขึ้นจริง เราจึงพูดได้ว่าผู้พัฒนาแก้พฤติกรรมนี้ แต่ยังพูดไม่ได้ว่าเกิดความเสียหายกับผู้ใช้กลุ่มใดมากน้อยเท่าไร (GitHub)

สำหรับเหตุการณ์ความปลอดภัย ข้อความที่มีไม่ได้ให้รายละเอียดการเก็บรักษา ผู้มีสิทธิ์อ่านบันทึก หรือข้อมูลที่จะปรากฏทุกช่อง ผมแนะนำให้ทีมตรวจสิ่งเหล่านี้จากผลทดสอบและนโยบายของตนก่อนเปิดใช้กับงานจริง การมีชื่อเหตุการณ์เพิ่มขึ้นยังไม่ใช่คำตอบเรื่องการดูแลข้อมูลบันทึกทั้งหมด (GitHub)

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

คนใช้ทั่วไปและเจ้าของงาน

1. ขอให้ผู้ดูแลยืนยันรุ่นที่ติดตั้งจริง เอกสารแนะนำให้ตรวจด้วย claude --version แล้วนำไปเทียบกับแท็ก v2.1.307 ที่มีรายการแก้ไขชุดนี้ อย่าอาศัยเพียงวันที่เห็นข่าว (Claude Code Docs, GitHub)
2. ก่อนให้ AI ทำงานที่เปลี่ยนข้อมูล ขอให้ทีมแสดงจุดขออนุมัติและคำสั่งที่จะทำจริง ใช้การแก้ไข Recently denied เป็นรายการตรวจร่วมกัน เพราะรุ่นนี้ระบุว่าจะเห็นคำสั่งที่ถูกปฏิเสธแล้ว (GitHub)
3. เริ่มจากโครงการทดลองที่ทิ้งได้ ใช้ข้อมูลจำลอง และอย่าใส่รหัสผ่าน กุญแจเข้าถึงบริการ หรือข้อมูลรับรองของระบบงานจริง นี่เป็นคำแนะนำของผมเพื่อจำกัดผลกระทบระหว่างตรวจพฤติกรรม

นักพัฒนาและผู้เชื่อมเครื่องมือ

1. ทบทวนว่าเครื่องมือใดอ่านอย่างเดียว เครื่องมือใดทำซ้ำแล้วผลไม่เพิ่ม และเครื่องมือใดสร้างการเปลี่ยนแปลงเพิ่มเติมทุกครั้ง เพราะกติกาลองใหม่ของ HTTP MCP ในรุ่นนี้แยกตามคุณสมบัติดังกล่าว (GitHub)
2. ทดลองงานตัวอย่างในสภาพแวดล้อมทดสอบแล้วตรวจทั้งผลลัพธ์กับบันทึก อย่าสรุปว่าหน้าจอขึ้นข้อผิดพลาดเท่ากับไม่มีการเปลี่ยนข้อมูลเกิดขึ้น ข้อนี้เป็นแนวทางตรวจงานที่ผมเสนอเพื่อรับมือความไม่แน่นอนระหว่างการเชื่อมต่อ
3. หากดูแลโค้ดที่เรียก Claude API หรือช่องทางให้โปรแกรมติดต่อบริการ Claude รุ่นนี้เพิ่ม /claude-api api-version สำหรับย้ายโค้ดไปใช้ API version 2026-10-21 ควรแยกทดสอบการย้ายนี้จากการตรวจสิทธิ์เครื่องมือ เพื่อให้รู้ว่าแต่ละปัญหาเกิดจากส่วนไหน (GitHub)

ทีมไอทีและผู้ดูแลเครื่องรัน

1. ทดลองรับ claude_code.safety_event เข้าระบบรวมบันทึก แล้วตรวจว่าเหตุการณ์จากงานตัวอย่างอ่านเข้าใจและใช้ตามงานได้จริงก่อนตั้งการแจ้งเตือน แหล่งข่าวยืนยันการเพิ่มเหตุการณ์ แต่ไม่ได้ให้ผลการติดตั้งของระบบคุณ (GitHub)
2. ตรวจงานเตรียมโครงการบนเครื่องรันขององค์กรกับค่าเริ่มต้น 30 นาที หากต้องปรับให้บันทึกเหตุผลและทดสอบผลหลังเปลี่ยนด้วย (Claude Code Docs)
3. ตรวจแหล่งตั้งค่า axScreenReader ซึ่งเกี่ยวกับการใช้ตัวอ่านหน้าจอ เพราะบันทึกระบุว่าจะมีผลเฉพาะจากการตั้งค่าระดับผู้ใช้ ระดับที่องค์กรจัดการ หรือการตั้งค่าที่ระบุผ่านตัวเลือก --settings และระบุว่าการเปลี่ยนนี้มีมาตั้งแต่ 2.1.305 อย่านับเป็นพฤติกรรมที่เพิ่งเริ่มในรุ่นนี้ทั้งหมด (Claude Code Docs)

หลักฐานความปลอดภัยและความเสี่ยงที่ยังเหลือ

ที่มาของรุ่นตรวจย้อนกลับได้จากคลังทางการ anthropics/claude-code บน GitHub แท็ก v2.1.307 ลงวันที่ 21 ตุลาคม 2026 และหน้าเผยแพร่ระบุว่าเป็น immutable release ซึ่งหมายถึงตัวรุ่นถูกตรึงไว้ โดยยังแก้ชื่อและบันทึกประกอบได้ ข้อมูลนี้ช่วยยืนยันที่มาของสิ่งที่กำลังอ่าน แต่ไม่ได้เป็นผลตรวจความปลอดภัยอิสระ (GitHub)

ด้านประกาศความปลอดภัย ข้อความจากหน้า Security ที่ให้มามีเพียงนโยบายรายงานปัญหา ระบุว่าโครงการความปลอดภัยจัดการผ่าน HackerOne และให้ส่งช่องโหว่ที่ตรวจสอบแล้วผ่านแบบฟอร์มของโครงการ ข้อความนี้ไม่แสดงรายการประกาศช่องโหว่หรือหมายเลข CVE จึงใช้ยืนยันว่า “ไม่มีช่องโหว่ที่ทราบ” ไม่ได้ (GitHub Security)

เรื่องสิทธิ์เริ่มต้นต้องอ่านเงื่อนไขด้วย ประวัติวันที่ 16 ตุลาคมระบุว่าการใช้งานแบบสั่งครั้งเดียวและผ่าน Agent SDK ซึ่งเป็นชุดเครื่องมือสำหรับสร้างโปรแกรมที่ใช้เอเจนต์ หากไม่ได้กำหนดโหมดสิทธิ์ จะเริ่มใน default mode ในกรณีผู้ให้บริการภายนอก ปิด telemetry หรือเพิ่งติดตั้งใหม่ ส่วนการระบุโหมด auto ไว้ยังคงใช้ auto ข้อความนี้ไม่ได้แปลว่าทุกการติดตั้งมีรูปแบบอนุมัติเดียวกัน (Claude Code Docs)

ความเสี่ยงที่ยังเหลือในมุมของผมคือสิทธิ์และเครื่องมือที่เชื่อมไว้ยังต้องมีคนตรวจเอง อัปเดตนี้ทำให้เห็นเหตุการณ์เพิ่มและแก้พฤติกรรมบางจุด แต่หลักฐานที่มีไม่รองรับคำรับรองว่าปลอดภัยทั้งหมด ควรเริ่มในโครงการที่ทิ้งได้หรือสภาพแวดล้อมทดสอบเสมอ และอย่าใช้ข้อมูลรับรองของระบบงานจริงในการลองรอบแรก

ผมมองว่า…

ผมมองว่าในเชิงความเห็น จุดสำคัญของรุ่นนี้ไม่ใช่การให้ AI ทำงานแทนคนมากขึ้น แต่คือการทำให้คนตรวจว่ามันหยุด ขออนุญาต และลองใหม่อย่างไรได้ชัดขึ้น งานที่เสร็จเร็วมีประโยชน์ก็ต่อเมื่อเจ้าของงานเข้าใจผลที่เกิดตามมา และยอมรับได้ว่าระบบมีสิทธิ์ทำอะไรบ้าง

ผมให้น้ำหนักกับการแก้ส่งคำขอซ้ำและการอนุมัติที่ถูกนำไปใช้ตรงกัน มากกว่าจำนวนรายการเปลี่ยนแปลงทั้งหมด เพราะสองเรื่องนี้เอาไปตั้งคำถามกับงานประจำวันได้ทันที ส่วนบันทึกใหม่จะมีคุณค่ามากแค่ไหน ขึ้นอยู่กับว่าทีมอ่านแล้วตัดสินใจต่อได้หรือเปล่า บันทึกที่ไม่มีใครเปิดดูยังขยันสะสมตัวเองได้ดีครับ

ปิดท้าย: สิ่งที่ต้องจับตา

สิ่งที่ผมอยากติดตามคือเมื่อทีมลองใช้จริงแล้ว การแยกงานอ่านกับงานที่มีผลเปลี่ยนข้อมูลชัดเจนพอหรือยัง บันทึกความปลอดภัยช่วยลดเวลาหาสาเหตุได้หรือไม่ และเจ้าของงานเข้าใจสิ่งที่ตัวเองอนุมัติมากขึ้นเพียงใด ทั้งหมดนี้ควรตอบจากการทดลองของแต่ละทีม มากกว่าตีความจากชื่อรุ่นอย่างเดียว

อีกเรื่องคือรายการแก้ไขบอกว่าเมื่อคำขอเรียกเครื่องมืออยู่ในรูปแบบที่ระบบอ่านไม่เข้าใจ Claude Code จะลองใหม่ได้สูงสุดสองครั้งก่อนจบช่วงการทำงานด้วยข้อผิดพลาด นี่เป็นคนละกรณีกับการส่ง HTTP MCP ซ้ำเมื่อการเชื่อมต่อหลุด จึงควรแยกสองเหตุการณ์นี้ตอนอ่านบันทึกและประเมินปัญหา (GitHub)

Recap

• ตรวจรุ่นที่ติดตั้งจริงก่อนเทียบรายการเปลี่ยนแปลง
• แยกเครื่องมืออ่านข้อมูลออกจากเครื่องมือที่เปลี่ยนข้อมูล
• ตรวจคำสั่งจริงก่อนอนุมัติจากรายการที่เพิ่งถูกปฏิเสธ
• ทดลองบันทึกความปลอดภัยว่าทีมอ่านและนำไปใช้ได้
• ตรวจเวลาการเตรียมโครงการบนเครื่องรันขององค์กร
• แยกข้อความเตือนโควตาค้นเว็บออกจากการบังคับสิทธิ์เครือข่าย
• เริ่มจากโครงการที่ทิ้งได้และข้อมูลจำลอง
• ไม่ใช้ข้อมูลรับรองของระบบงานจริงในการทดลอง