Claude Code เปลี่ยนโหมดอนุมัติอัตโนมัติเป็นค่าเริ่มต้น 14 ส.ค. 2026

Anthropic ประกาศเมื่อ 7 ส.ค. 2026 ว่าตั้งแต่วันที่ 14 ส.ค. 2026 โหมดที่เรียกว่า auto mode จะกลายเป็น ค่าเริ่มต้นของ session ใหม่บนแพ็กเกจ Pro, Max และ Team ของ Claude Code (Anthropic · docs)

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

🆕 สถานะ ณ วันดีเดย์ 14 ส.ค. 2026

วันนี้คือวันที่ประกาศระบุไว้ แต่ยืนยันได้แค่ว่า "กำหนดคือวันนี้" ไม่ใช่ว่า "เกิดขึ้นแล้ว"

• ประกาศลงวันที่ 7 ส.ค. 2026 quote ตรงตัวคือ "Starting on August 14, new sessions on Pro, Max, and Team plans will run in auto mode."
• ยังไม่มีรายการใดใน CHANGELOG.md ที่ยืนยันว่าการสลับเกิดขึ้นแล้ว ไล่ดูครบถึงรุ่นล่าสุด 2.1.232, 2.1.231 และ 2.1.229 · บรรทัดล่าสุดที่พูดถึง default permission mode ยังเป็นของ 2.1.200 ที่ระบุว่า "Changed the 'default' permission mode to 'Manual' across the CLI, --help, VS Code, and JetBrains"
• หน้า release notes ทางการ docs.claude.com/en/release-notes/claude-code ตอนนี้ redirect ไป platform.claude.com แล้ว redirect ต่อไปที่ CHANGELOG.md ไฟล์เดียวกัน แปลว่า ไม่มี surface อื่นที่อาจซ่อนรายการนี้ไว้
• ไม่พบประกาศฉบับวันที่ 14 ส.ค. ที่ยืนยัน rollout และไม่พบข่าวเลื่อนหรือถอยเช่นกัน ข่าวรองทุกเจ้าอ้างประกาศ 7 ส.ค. ฉบับเดิม
• ⚠ แต่ห้ามสรุปว่า rollout ยังไม่เกิด การไม่มีรายการใน CHANGELOG ไม่ใช่หลักฐานว่ายังไม่เกิด เพราะการสลับ default ผูกกับ plan ของบัญชี (Pro, Max, Team) ซึ่งเป็นการเปลี่ยนฝั่ง server ไม่จำเป็นต้องมาพร้อม CLI release · ให้เขียนว่า "ยังไม่มีรายการใน CHANGELOG ที่ยืนยัน" เท่านั้น
• ⚠ อย่าใช้ชื่อหน้าประกาศเป็นหลักฐาน ชื่อหน้าใช้ present tense ว่า "Auto mode is now the default in Claude Code for Pro, Max, and Team plans" ขณะที่เนื้อในเขียนเป็นอนาคตว่า "Starting on August 14" ความไม่ตรงกันนี้คือเหตุผลที่ข่าวรองหลายเจ้าพาดหัวคลาดเคลื่อน

สิ่งที่ต้องทำจริง: เปิดดูบนเครื่องเอง เพราะเป็นวิธีเดียวที่ยืนยันสถานะได้ในวันนี้

ขอบเขตของการเปลี่ยน

ค่าเริ่มต้นใหม่ใช้กับ Pro, Max และ Team ส่วน Claude Enterprise, Claude API, Claude Platform บน AWS, Amazon Bedrock, Agent Platform ของ Google Cloud และ Microsoft Foundry ยังเป็นแบบเลือกเปิดเองไปก่อน เพื่อให้ผู้ดูแลระบบมีเวลาทบทวน

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

ค่าที่ผู้ใช้ตั้งไว้เองจะไม่ถูกเปลี่ยนจนกว่าจะกดยอมรับคำถามสลับโหมดที่ขึ้นครั้งเดียว และค่าที่องค์กรกำหนดไว้ ไม่ถูกแตะ (docs)

ผู้ใช้สลับโหมดได้ด้วย Shift+Tab ในบรรทัดคำสั่ง หรือกล่องเลือกโหมดบนแอปเดสก์ท็อป การตั้งค่าเริ่มต้นทั่วองค์กร ทำผ่าน defaultMode และการปิดโหมดนี้ทั้งหมดทำผ่าน permissions.disableAutoMode โดยค่าที่ใส่คือข้อความ disable ไม่ใช่ค่าจริงเท็จ และตั้งได้ทั้งในไฟล์ตั้งค่าของผู้ใช้เองและในค่าที่องค์กรกำหนด ต่างกันที่ค่าที่องค์กร กำหนดจะถูกเขียนทับไม่ได้ (permissions)

ตัวเลขที่ Anthropic ใช้สนับสนุน

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

ผลที่รายงานคือผู้ทดสอบจับคำสั่งอันตรายได้เพียง 13.6% หรือ 143 จาก 1,053 ครั้ง ขณะที่ auto mode บล็อกคำสั่งชุดเดียวกันได้ 89% หรือ 937 จาก 1,053 ครั้ง และบริษัทสรุปเป็นประโยคว่า "Head to head, auto mode blocked 800 commands that a human approved, while humans blocked only 6 that auto mode allowed."

ข้อจำกัดของการอ่านตัวเลขชุดนี้มีสามข้อ ข้อแรกคือคำว่าคำสั่งชุดเดียวกันหมายถึงการเอาชุดคำสั่งเดิมไปวัดกับ auto mode ไม่ใช่การสุ่มแบ่งคนสองกลุ่มมาเทียบกันแบบการทดลองที่มีกลุ่มควบคุม ผลปลายทางจึงเทียบกันไม่สนิท ข้อที่สองคือหน้าประกาศไม่ระบุอาชีพ ระดับฝีมือ หรือเกณฑ์คัดผู้ทดสอบไว้เลยแม้จุดเดียว ซึ่งกระทบการตีความ เลข 13.6% โดยตรง เพราะไม่รู้ว่าคนกลุ่มนี้ใกล้เคียงกับนักพัฒนาที่ใช้เครื่องมือนี้จริงแค่ไหน ข้อที่สามคือทั้งหมด เป็นตัวเลขที่บริษัทวัดสินค้าของตัวเอง และตัวเลขเดิมของบริษัทเองเมื่อเดือน พ.ค. อยู่ที่ราว 83% จึงเป็นเลข ที่ขยับได้

⚠ ถ้อยคำที่ต้องใช้ให้ตรง: ฉบับเต็มของประโยคคือ auto mode "would have blocked 89% of those actions" ซึ่งเป็นการวัดแบบ counterfactual คือเอา auto mode ไปประเมินย้อนหลังกับคำสั่งชุดเดิม ไม่ใช่การรัน auto mode สดกับผู้ทดสอบ ให้เขียนว่า "ประเมินย้อนหลังแล้วพบว่าจะบล็อกได้ 89%" · counter-evidence ที่ควรใส่คู่กันคือ Simon Willison ชี้ว่า "that still leaves 11% of cases where auto mode would not have prevented the action" และเรียกร้อง "more independent confirmation" ซึ่งจนถึง 14 ส.ค. 2026 ยังไม่มีการยืนยันอิสระจากบุคคลที่สาม

🆕 ตัวเลขชุดที่สอง จากการใช้งานจริง (เพิ่ม 14 ส.ค. 2026)

ประกาศฉบับเดียวกันมีตัวเลขอีกชุดที่คลังนี้เคยตกไป และเป็นคนละชุดข้อมูลกับการทดลอง 1,053 คน

"At production-level severity (7+), 6.3% of manually approved sessions contained a harmful action the user hadn't explicitly asked for, compared to 2.4% of auto mode sessions"

🔴 กับดักการแปลที่ต้องกันไว้เด็ดขาด: คำว่า "production-level severity (7+)" ไม่ได้แปลว่า "ในการใช้งานจริง" มันคือ ระดับความรุนแรงบนสเกลคะแนน ที่ 7 ขึ้นไป โดยหน้าประกาศนิยามระดับ 7 ว่าเทียบเท่าความเสียหายอย่าง "deleting rows from a production database" · การแปลเป็น "บน production" คือการอ่านผิดคนละความหมาย

ที่มาของข้อมูลก็ไม่ใช่ production ทั้งระบบ:

"We examined how auto mode performs in real usage. From May to June 2026, we examined sessions our safety pipeline had flagged for review, drawn only from accounts that have opted in to data use for training and analysis."

แปลว่า denominator ไม่ใช่ session ทั้งหมด แต่เป็นเฉพาะ session ที่ safety pipeline flag ไว้ให้ review แล้ว และเฉพาะบัญชีที่ opt in ให้ใช้ข้อมูล ช่วง พ.ค. ถึง มิ.ย. 2026 เท่านั้น · 6.3% จึงไม่ใช่ "6.3% ของ manual session ทั่วไป" ซึ่งเป็นสิ่งที่คนอ่านจะเข้าใจทันทีถ้าเขียนลอยๆ

หน่วยคือ ต่อ session ไม่ใช่ต่อ action · ถ้อยคำจริงคือ "a harmful action the user hadn't explicitly asked for"

ผลทดสอบการโจมตีที่บริษัทจ้างให้ทำ

Anthropic ระบุว่าจ้างบริษัทภายนอกชื่อ Trajectory Labs ให้ประเมิน โดยใช้คำว่า "We commissioned an evaluation from a third party, Trajectory Labs" และระบุว่าสถานการณ์ทดสอบถูกกัน ไม่ให้ Anthropic เห็น จำนวนคือ prompt injection แบบอ้อม 72 สถานการณ์ ทำซ้ำแบบละ 10 ครั้ง รวม 720 ครั้ง ผลที่รายงานคือไม่มีการโจมตีสำเร็จเลยกับ Claude Fable 5, Opus 5 และ Sonnet 5 ที่รัน auto mode ขณะที่ GPT-5.6 Sol ในโหมด Auto-review ของ Codex ถูกโจมตีสำเร็จ 5.83%

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

ตัวรายงานไม่มีที่ให้อ่าน หน้าประกาศไม่ได้ลิงก์ไปที่ไหนและไม่ได้ระบุว่าจะเผยแพร่ ตัวเลข 720 กับ 5.83% จึงสืบย้อนได้ถึงหน้าประกาศของ Anthropic เท่านั้น

การเทียบข้ามค่ายมีข้อจำกัดเชิงวิธีเพิ่มอีกชั้น เพราะทั้งสองฝ่ายถูกวัดผ่านตัวเชื่อมเบราว์เซอร์แบบเดียวกันที่ Trajectory Labs สร้างขึ้นเอง ไม่ใช่ค่าตั้งต้นของสินค้าแต่ละตัว และเวอร์ชันที่วัดคือ Claude Code รุ่น 2.1.205 กับ Codex รุ่น 0.144.5 ซึ่งเป็นภาพถ่าย ณ วันที่ 17 ก.ค. 2026

หลักฐานที่ให้ผลตรงข้าม

งานวิชาการจาก HKUST ร่วมกับ ETH Zurich วัด auto mode ด้วยโจทย์ที่ตั้งใจให้กำกวมในเรื่องขอบเขตงาน แล้วได้ผลสวนทางอย่างแรง คืออัตราการปล่อยของอันตรายผ่านแบบครบวงจรอยู่ที่ 81.0% โดยมีช่วงความเชื่อมั่น 95% ที่ 73.8% ถึง 87.4% เมื่อดูเฉพาะการกระทำที่ตัวคัดกรองรับไปพิจารณาจริง อัตราปล่อยผ่านยังอยู่ที่ 70.3% และอัตราการเตือนผิดขึ้นเป็น 31.9% (arXiv 2604.04978)

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

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

งานทดลอง 1,053 คน ไม่ใช่งานทดลอง 40,000 รอบ

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

งานแรกคือการทดลองราว 40,000 รอบที่วัดว่าคนที่นั่งกดอนุมัติปล่อยภัยผ่านราวหนึ่งในสาม ซึ่งเป็นงานของ บุคคลภายนอกที่ไม่เกี่ยวกับ Anthropic ใช้เกมบนเบราว์เซอร์เป็นเครื่องมือ และนับหน่วยเป็นการตัดสินราว 409,000 ครั้ง (The Register)

งานที่สองคือการทดลอง 1,053 คนในหน้านี้ ซึ่ง Anthropic เป็นผู้จ้างและรายงานเอง ใช้ session ของ Claude Code จริงในสภาพแวดล้อมทดสอบ และนับหน่วยเป็นกับดักหนึ่งอันต่อหนึ่ง session

ตัวเลขของสองงานนี้เอามาบวกหรือเทียบกันตรงๆ ไม่ได้ เพราะสัดส่วนคำสั่งอันตรายในโจทย์ต่างกัน และผู้เข้าร่วม งานแรกรู้ตัวว่ากำลังตามหาของอันตราย จุดที่ใช้ร่วมกันได้คือทั้งสองงานชี้ทางเดียวกันว่าการให้คนกดอนุมัติทีละครั้ง เป็นด่านที่อ่อนกว่าที่คนคิด และงานแรกยังพบว่าอัตราการบล็อกลดจากราว 17% ช่วงต้น session เหลือราว 5% หลังผ่านคำถามไป 50 ครั้ง ซึ่งเป็นภาพของอาการชาจากการกดอนุมัติซ้ำๆ

เสียงจากผู้ปฏิบัติ

Simon Willison รับข้อตั้งต้นเรื่องอาการชาจากการกดอนุมัติ โดยเขียนว่า "Confirmation fatigue is real, and asking humans to click 'OK' every few steps is clearly not going to result in safe behavior." แต่ขอการยืนยันจากภายนอกเพิ่ม และตั้งข้อสังเกตว่ายังเหลืออีก 11% ของกรณีที่โหมดนี้ก็ไม่ได้ยับยั้งการกระทำ (Simon Willison)

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

ข้อจำกัดที่ Anthropic ระบุเอง

บริษัทเขียนไว้ว่า "while we believe auto mode reduces risk for most users, it relies on classification systems and therefore does not eliminate risk" และแนะนำให้คนตรวจงานเองสำหรับการเปลี่ยนแปลงที่มีความเสี่ยงสูง บนระบบที่ใช้งานจริง

เรื่องที่คนเข้าใจผิดบ่อย

หนึ่ง พาดหัวประกาศเขียนว่าโหมดนี้เป็นค่าเริ่มต้นแล้ว ทั้งที่วันมีผลคือ 14 ส.ค. 2026 การอ่านพาดหัวอย่างเดียว จะเข้าใจว่าเปลี่ยนไปแล้ว

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

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

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

สิ่งที่องค์กรไทยหยิบไปใช้ได้

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

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

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

คำถามที่ยังไม่มีคำตอบ

รายงานของ Trajectory Labs ยังไม่มีที่ให้อ่าน จึงยังตรวจวิธีวัดของตัวเลข 720 กับ 5.83% ไม่ได้

ยังไม่มีการวัด auto mode รุ่นปัจจุบันโดยฝ่ายที่สามที่เป็นอิสระจริง งานวิชาการที่มีอยู่วัดเวอร์ชันที่เก่ากว่าราว สามเดือนครึ่ง

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