Claude Code 2.1.314 คืออะไร? ตั้งค่ากั้นไม่ให้ AI เขียนไฟล์นอกโฟลเดอร์งาน ได้ผลแค่ไหน?

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

รีลีส 2.1.314 ของ Claude Code เมื่อ 30 ต.ค. 2026 ตอบคำถามนี้ตรง ๆ ด้วยการเพิ่มค่าตั้งชื่อ permissions.blockWritesOutsideWorkingDirectories

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

ตัวเปลี่ยนเกมคือค่าตั้งเดียว คือ permissions.blockWritesOutsideWorkingDirectories

ความหมายตามรีลีสโน้ตคือเครื่องมือ Write, Edit และ NotebookEdit จะปฏิเสธทุกพาธที่อยู่นอก working directory ใน ทุก permission mode

คำว่า "ทุก permission mode" สำคัญมาก เพราะมันรวม bypassPermissions ด้วย ซึ่งเป็นโหมดที่ผู้ใช้มักเปิดไว้เวลาอยากให้ AI ทำงานเร็ว ๆ โดยไม่ต้องกดอนุญาตทีละครั้ง

นอกจากนั้นยังมีอีกสองเรื่องที่มากับรีลีสเดียวกัน

รีลีสนี้มีบรรทัดที่ขึ้นต้นด้วยคำว่า Fixed อยู่ 63 บรรทัด และคำว่า Fixed ปรากฏในโน้ตทั้งหมด 81 ครั้ง นี่คือรีลีสซ่อมบั๊กขนาดใหญ่ ไม่ใช่รีลีสฟีเจอร์เล็ก

หลายคนเข้าใจผิดว่าโหมด bypassPermissions หรือ acceptEdits คือเขตกั้นว่ามันเขียนไฟล์ได้แค่ในโปรเจกต์

ความจริงคือสองโหมดนั้นเป็นเรื่องของ การขออนุญาต ไม่ใช่ ขอบเขตของพาธ ถ้าคำสั่งเขียนไฟล์ชี้ไปที่ ~/Documents/report.md และโหมดอนุญาตให้เขียนได้ มันก็เขียนได้

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

ในมุมมองของผม นี่คือการยอมรับทางอ้อมว่า ระบบขออนุญาตแบบเดิมกันพลาดได้ เพราะคนกด Allow รัว ๆ จนไม่ทันอ่านพาธ

สรุปข่าวที่ส่งมาวันนี้มีหนึ่งประโยคที่ทำให้เข้าใจผิด ผมจึงไปเปิดต้นฉบับเทียบ

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

เปิดรีลีสโน้ตบรรทัดจริงแล้ว เงื่อนไขแคบกว่านั้นมาก ข้อความเต็มเขียนว่า flagged requests จะ retry บนโมเดลอื่นแทนการจบด้วย refusal เมื่อ ANTHROPIC_DEFAULT_OPUS_MODEL, availableModels หรือ deniedModels เหลือโมเดล Opus แค่รุ่นเก่า หรือไม่เหลือเลย

แปลว่ากลไกนี้ทำงานในกรณีที่การตั้งโมเดลของคุณบีบให้เหลือตัวเลือกแย่ ๆ ไม่ใช่ทุกครั้งที่ระบบตั้งธงความปลอดภัย

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

นี่คือส่วนที่ผมคิดว่าคนจะพลาดมากที่สุด และรีลีสโน้ตก็ไม่ได้ปิด

ค่าตั้งนี้คุมเฉพาะ Write, Edit และ NotebookEdit ไม่ได้คุมคำสั่ง shell

เอกสารเขียนไว้ตรง ๆ ว่า Claude Code ไม่ได้ปฏิเสธคำสั่ง shell ด้วยวิธีเดียวกัน แปลว่าคำสั่งอย่าง echo... > ~/note.txt หรือ sed -i ยังเขียนไฟล์นอกโฟลเดอร์งานได้ตามสิทธิ์ของเชลล์ ถ้าคุณไม่ได้เปิดแซนด์บ็อกซ์ ซึ่งค่าเริ่มต้นคือปิด

ทางปิดช่องนี้ที่ผมแนะนำก่อนคือ /sandbox ในเซสชัน หรือตั้ง sandbox.enabled: true แล้วคุมเส้นทางด้วย sandbox.filesystem.denyWrite เพราะแซนด์บ็อกซ์บังคับที่ขอบระบบปฏิบัติการ ครอบทุกโปรเซสลูกที่คำสั่งนั้นเรียกขึ้นมา

การรันในคอนเทนเนอร์ยังเป็นทางเลือกที่แข็งแรงกว่า ถ้าคุณต้องการแยกไฟล์ระบบออกจากกันจริง ๆ

อีกจุดที่ผมยังตอบไม่ได้คือตัวเลือกใหม่นี้ตัดสิน symlink อย่างไร เพราะเอกสารอธิบายการจัดการ symlink ไว้เฉพาะของ permission rule กับแซนด์บ็อกซ์ แต่ไม่ได้ระบุถึงค่าตั้งตัวนี้ และผมไม่ได้ทดลองเอง

ส่วนโฟลเดอร์ที่เพิ่มด้วย --add-dir หรือ permissions.additionalDirectories นั้น เอกสารของค่าตั้งฝั่งอ่านระบุว่านับเป็น working directory ของการบล็อก ถ้าอยู่ใน settings ระดับผู้ใช้หรือ managed ส่วนที่วางใน.claude/settings.json ของโปรเจกต์ไม่นับ ผมคาดว่าฝั่งเขียนใช้กรอบเดียวกัน แต่ยังไม่มีข้อความยืนยันตรง ๆ

ค่าตั้งฝั่งอ่านมีอยู่แล้วในชื่อ permissions.blockReadsOutsideWorkingDirectories และต้องใช้ตั้งแต่เวอร์ชัน 2.1.257 ส่วนค่าตั้งฝั่งเขียนเพิ่งมาถึงในรีลีสนี้ และ ณ วันนี้หน้าตั้งค่ายังไม่มีชื่อค่านี้ (ผมตรวจ 6 หน้าแล้ว)

รีลีสแบบนี้ไม่ได้มีผลกับทุกคน ผมจึงแยกให้เห็นว่าใครได้และใครไม่ได้ เกณฑ์ของผมคือเครื่องที่รัน LLM และ agent อยู่บนเครื่องเดียวกับไฟล์งาน

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

ขั้นตอนสั้นมาก แต่มีจุดที่ต้องระวังตอนทดสอบ

เพิ่มบรรทัดนี้ในไฟล์ตั้งค่าของโปรเจกต์หรือของผู้ใช้

{ "permissions": { "blockWritesOutsideWorkingDirectories": true } } Enter fullscreen mode Exit fullscreen mode จากนั้นรีสตาร์ตเซสชัน Claude Code แล้วลองให้มันเขียนไฟล์นอกโฟลเดอร์งาน ตัวอย่างเช่นให้มันสร้างไฟล์ที่ ~/test-outside.md แล้วดูว่ามันปฏิเสธหรือไม่

ถ้ามันยังเขียนได้ แปลว่าการเขียนครั้งนั้นไม่ได้ผ่าน Write, Edit หรือ NotebookEdit โดยปกติแล้วจะผ่าน Bash หรือเครื่องมือ MCP หรือ hook ซึ่งเป็นช่องที่ผมเล่าไว้ข้างบน

permissions.blockWritesOutsideWorkingDirectories เป็นการเพิ่มที่ผมรอ เพราะมันปิดช่องที่คนใช้จริงเจอบ่อย คือการกด Allow โดยไม่ดูพาธ

แต่ในมุมมองของผม มันยังไม่ใช่กำแพงกันไฟล์ทั้งเครื่อง เพราะ Bash ยังอยู่นอกขอบเขตของมัน และเอกสารยังไม่ทันโค้ด

ถ้าคุณต้องการแยก AI ออกจากไฟล์สำคัญจริง ๆ ให้ถือว่ารีลีสนี้เป็นชั้นป้องกันชั้นแรก ไม่ใช่ชั้นเดียว

GitHub Releases · anthropics/claude-code v2.1.314 (เผยแพร่ 30 ต.ค. 2026 01:06 UTC) · https://github.com/anthropics/claude-code/releases/tag/v2.1.314 Claude Code Docs · Settings reference (เข้าถึง 31 ต.ค. 2026) · https://code.claude.com/docs/en/settings-reference Claude Code Docs · Permissions (เข้าถึง 31 ต.ค. 2026) · https://code.claude.com/docs/en/permissions Claude Code Docs · Sandboxing (sandbox off by default · ขอบเขต writes เริ่มต้น) · เข้าถึง 31 ต.ค. 2026 · https://code.claude.com/docs/en/sandboxing

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)