Claude Code: המצב האוטומטי הופך לברירת המחדל

מה משתנה במצב האוטומטי ב־14 באוגוסט 2026

המצב האוטומטי של Claude Code מפעיל קריאות לכלים בלי לעצור ולבקש את אישורך, ושולח כל פעולה למודל מסווג נפרד לבדיקה מקדימה. החל מ־14 באוגוסט 2026, זהו המצב שבו יתחילו הפעלות חדשות בתוכניות Pro, Max ו־Team. אפשר לעבור בין המצבים בכל עת, והגדרת ברירת מחדל שכבר קבעת לעצמך לא תוחלף.

התיעוד מתאר את השינוי כך:

החל מ־14 באוגוסט 2026, המצב האוטומטי יהיה מצב ההרשאות המוגדר כברירת מחדל בהפעלות חדשות בתוכניות Pro, Max ו־Team. אפשר לעבור בין המצבים בכל עת. ברירת מחדל שהגדרת בעצמך תישאר בתוקף, אלא אם תאשר את בקשת המעבר החד־פעמית, וברירת מחדל שהארגון שלך מנהל לא תשתנה.

שני סעיפים כאן חשובים יותר מהתאריך. defaultMode שהגדרת בקובץ ההגדרות האישי שלך יישאר בתוקף לאחר השינוי. גם ברירת מחדל שהארגון שלך מפיץ באמצעות הגדרות מנוהלות תישאר בתוקף. הפוסט של ההודעה מוסיף שהמצב האוטומטי יישאר אופציונלי בתוכניות Enterprise ובחשבונות המשתמשים ב־API במהלך השלב הראשון של ההפצה.

אם אתה מפעיל את Claude Code ב־VPS (שרת פרטי וירטואלי), כדאי לקרוא על השינוי לפני שהוא ייכנס לתוקף. בקשת הרשאה היא נקודת ביקורת שמחייבת אדם מול המקלדת. בשרת מרוחק בדרך כלל אינך נמצא מולו, ולכן המצב שבו ההפעלה מתחילה הוא המצב שיישאר פעיל במשך שעות.

מצבי ההרשאות של Claude Code, מרמת הפיקוח הגבוהה ביותר לנמוכה ביותר

יש שישה מצבים. השם בתחילת כל שורה הוא הערך שכותבים בהגדרות או מעבירים אל --permission-mode. Claude Code עצמו אוכף את כל ששת המצבים, ולא המודל, משום שההחלטה אילו פעולות מותר לקריאת כלי לבצע היא באחריות המעטפת שסביב המודל.

• default: Claude מבקש אישור לפני כל שימוש חדש בכלי. קריאות בתוך ספריית העבודה עדיין פועלות ללא בקשת אישור. ה־CLI (ממשק שורת הפקודה) מציג את המצב הזה בשם Manual ומקבל את manual ככינוי מ־Claude Code v2.1.200.
• plan: Claude קורא קבצים ומריץ פקודות לצורכי בדיקה, ואינו עורך את קוד המקור. עריכות נשארות חסומות עד לאישור התוכנית.
• acceptEdits: עריכת קבצים מתבצעת ללא בקשת אישור, וכן פקודות מערכת הקבצים mkdir, touch, rm, rmdir, mv, cp ו־sed. הדבר חל רק על נתיבים בתוך ספריית העבודה או בתוך additionalDirectories. כל פקודת shell אחרת עדיין מחייבת אישור.
• auto: הכול מתבצע, כאשר המסווג בודק תחילה כל פעולה. כללי ask מפורשים עדיין מחייבים בקשת אישור.
• dontAsk: Claude Code דוחה אוטומטית כל פעולה שהייתה מחייבת בקשת אישור. רק כללי allow, פקודות Bash המובנות לקריאה בלבד וקריאות שה־hook של PreToolUse מאשר יופעלו. הסשן לעולם אינו ממתין לקלט.
• bypassPermissions: בקשות האישור ובדיקות הבטיחות מדולגות, כולל כתיבה לנתיבים מוגנים כגון .git ו־.claude.

לחצו על Shift+Tab במהלך סשן כדי לעבור מ־default ל־acceptEdits ול־plan. שורת המצב מציגה את המצב שנבחר, כגון ⏵⏵ auto mode on או ⏸ manual mode on אפור. שאר המצבים אינם נכללים במחזור הזה כברירת מחדל. auto מצטרף אליו לאחר שהחשבון עומד בדרישות המתאימות. bypassPermissions מצטרף אליו רק כאשר הסשן הופעל באמצעות --permission-mode bypassPermissions או --dangerously-skip-permissions. dontAsk לעולם אינו מופיע במחזור הזה, ולכן יש להגדיר אותו באמצעות claude --permission-mode dontAsk.

מצב אוטומטי דורש גם מודל עדכני, וזו בדרך כלל הסיבה לכך שהוא כלל אינו מופיע. נכון ל־August 2026, התיעוד מציין את Claude Opus 4.6 ומעלה, את Sonnet 4.6 ומעלה ואת Fable 5 ב־Anthropic API, ומבהיר שמודלים ישנים יותר, כגון Sonnet 4.5, אינם נתמכים אצל אף ספק. אם Claude Code מדווח שמצב אוטומטי אינו זמין, אחת מהדרישות האלה אינה מתקיימת. אין מדובר בהשבתה זמנית, ולכן המתנה לא תפתור את הבעיה.

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

מה חוסם המסווג במצב אוטומטי

המסווג הוא מודל נוסף שקורא את הפעולה הממתינה ומחליט אם היא תואמת למה שביקשת. התיעוד מתאר את תפקידו במשפט אחד:

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

חסומות כברירת מחדל, בקטגוריות שמפעיל שרת נתקל בהן בתדירות הגבוהה ביותר:

• הורדה והרצה של קוד, כגון curl | bash
• פריסות ו־migrations בסביבת production
• force push
• שינוי תשתית משותפת
• פתיחת tunnel או reverse shell שהופכים שירות מקומי לזמין מהאינטרנט הציבורי
• הדפסת credential או token פעילים לתמליל או לקובץ

מותרות כברירת מחדל:

• פעולות על קבצים מקומיים בספריית העבודה שלך
• התקנת תלויות שהוגדרו בקובצי lock או בקובצי manifest
• בקשות HTTP לקריאה בלבד
• דחיפה לכל branch במאגר שבו אתה עובד

אל תסתמך על סיכום כמו זה שלמעלה. הרץ את claude auto-mode defaults כדי להדפיס את רשימות הכללים המלאות בפורמט JSON, וקרא את קבוצת הכללים שסופקה עם הגרסה המותקנת אצלך.

לפני שמסתמכים על מנגנון זה, חשוב להכיר שתי מגבלות מתועדות. ראשית, המסווג רואה את ההודעות שלך, את קריאות הכלים ואת תוכן CLAUDE.md שלך, אך תוצאות הכלים מוסרות. לכן טקסט בתוך קובץ או בדף אינטרנט ש־Claude קרא אינו יכול לפנות ישירות למסווג. שנית, כאשר המסווג חוסם פעולה 3 פעמים ברציפות או 20 פעמים במהלך סשן אחד, המצב האוטומטי מושהה ו־Claude Code חוזר לבקש ממך אישור. אי אפשר להגדיר את הספים האלה. במצב לא־אינטראקטיבי, עם הדגל -p, אין מי שייתן תשובה לבקשת האישור. לכן חסימות חוזרות מפסיקות את הסשן במקום זאת.

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

היכן מוגדרים המצבים בקובץ settings.json

כל מה שמופיע למעלה הוא אובייקט אחד בקובץ הגדרות.

{
  "permissions": {
    "defaultMode": "auto",
    "allow": [
      "Bash(npm run test *)",
      "Bash(git status)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(docker compose up *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

הכללים נבדקים לפי הסדר: deny, לאחר מכן ask, ולבסוף allow. ההתאמה הראשונה בסדר הזה קובעת את התוצאה, וכלל מצומצם יותר אינו גובר על כלל רחב יותר שמופיע לפניו. כלל deny עבור Bash(aws *) חוסם את aws s3 ls, גם אם אישרתם במפורש את אותה פקודה. לכן אי אפשר להוסיף חריגים לכלל deny.

ask הוא סוג הכלל שמצדיק את קיומו במצב auto. מצב auto מסיר את בקשת האישור השגרתית, וכלל ask מחזיר אותה עבור הפקודה הספציפית שלגביה נדרש אישור אנושי. פקודת ה־deploy שלכם צריכה להיות מוגדרת שם. כך גם Bash(git push *), אם אתם רוצים נקודת ביקורת לפני שהקוד יוצא מהשרת. שמירת קובצי פרטי ההתחברות בתוך deny היא החלק המשלים של ההגדרה, והיא משתלבת עם הרחקת פרטי ההתחברות מהישג ידו של agent מלכתחילה.

קובצי ההגדרות עצמם, לפי סדר קדימות עולה:

• ~/.claude/settings.json: ההגדרות של המשתמש שלכם, המוחלות בכל פרויקט.
• .claude/settings.json: הגדרות הפרויקט, הנשמרות ב־repository.
• .claude/settings.local.json: ההגדרות האישיות שלכם עבור repository אחד, שאינן נכללות ב־git.
• הגדרות מנוהלות, הנפרסות על ידי מנהל מערכת. ב־Linux הקובץ הזה הוא /etc/claude-code/managed-settings.json. שום הגדרה אינה גוברת על כלל הרשאות מנוהל, כולל דגל בשורת הפקודה.

יש כאן מלכודת אחת עם סיבה מתועדת. המערכת מתעלמת מ־defaultMode: "auto" כאשר הוא מגיע מתוך .claude/settings.json או .claude/settings.local.json, החל מ־Claude Code v2.1.142, כדי ש־repository לא יוכל להפעיל לעצמו מצב auto באמצעות קובץ הגדרות שנכלל בו. אם תגדירו אותו שם, הסשן יתחיל במצב default בלי שתודפס שגיאה. העבירו את השורה אל ~/.claude/settings.json. הפעילו את /permissions כדי להציג כל כלל פעיל לצד הקובץ שממנו הגיע.

שני המתגים שמכבים מצב

למנהלי מערכת יש שני מתגי השבתה, ושניהם מקבלים את המחרוזת "disable" ולא ערך בוליאני.

{
  "permissions": {
    "disableAutoMode": "disable",
    "disableBypassPermissionsMode": "disable"
  }
}

התיעוד מדויק לגבי המקום שבו יש להגדיר אותם:

כדי למנוע שימוש במצב bypassPermissions או auto, הגדירו את permissions.disableBypassPermissionsMode או permissions.disableAutoMode לערך "disable" בכל קובץ הגדרות. אפשרויות אלה שימושיות במיוחד בהגדרות מנוהלות, שבהן אי אפשר לעקוף אותן.

disableAutoMode מסיר את auto ממחזור Shift+Tab ודוחה את --permission-mode auto בעת האתחול. disableBypassPermissionsMode מבצע את אותה פעולה עבור מצב העקיפה, והוא פועל מכל תחום, כך שאפשר להגדיר אותו ב־~/.claude/settings.json שלכם כדי למנוע מכם להפעיל מצב שלא תרצו להגיע אליו בשעה 2am בשרת פעיל. במחשב שמשמש אנשים אחרים, הגדירו את שניהם ב־/etc/claude-code/managed-settings.json במקום זאת, משום שקובץ הגדרות של משתמש שייך למשתמש, ואילו קובץ מנוהל אינו שייך לו.

מדוע מצב auto ב־VPS דורש גבול בידוד

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

המסווג הוא מנגנון בקרה לכל פעולה, ולא גבול בידוד. לכן גבול בידוד עדיין מספק שכבת הגנה נוספת בהרצות ללא השגחה, ואין חובה להשתמש בו כפי שנדרש עבור --dangerously-skip-permissions.

לכן השילוב המתאים לשרת מרוחק הוא מצב auto וסביבה שאתם מוכנים לאבד, ולא bypassPermissions ותקווה. מצב bypass מתועד עבור סביבות מבודדות בלבד: מכולות, מכונות וירטואליות או dev containers ללא גישה לאינטרנט, שבהן Claude Code אינו יכול לפגוע במערכת המארחת. VPS שמפעיל את מסד הנתונים ואת ה־reverse proxy שלכם אינו אף אחת מהאפשרויות האלה.

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

Claude Code אוכף בעצמו את האיסור על root. ב־Linux וב־macOS הוא מסרב להתחיל במצב bypass תחת sudo או כ־root:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

הבדיקה הזאת מדולגת בתוך sandbox מזוהה. לכן ההמלצה המתועדת לעבודה אוטונומית במכולה היא dev container שמפעיל את Claude Code כמשתמש שאינו root. אם אתם מפעילים את הסוכן מטלפון או ממחשב נייד באמצעות SSH, אותו היגיון חל על סשן Claude Code ממושך שנשאר פתוח בתוך tmux: איש אינו עוקב אחר ההנחיה בזמן שהסשן פועל. שום דבר מכל זה לא מתחיל לפני שההתחברות עצמה עובדת. לכן, אם השרת דוחה אתכם עם Permission denied (publickey), פלט ה־SSH המפורט יראה איזו מבין חמש התקלות קיימת אצלכם בפועל.

הגדרת ארגז חול של Bash ב־Ubuntu VPS

ארגז החול המובנה מגביל את הגישה של כל פקודת Bash ש־Claude מריץ למערכת הקבצים ולרשת. מערכת ההפעלה אוכפת את ההגבלות האלה גם על תהליכי צאצא. ב־Linux נדרשות שתי חבילות.

sudo apt-get install bubblewrap socat

הפעילו את Claude Code והריצו את /sandbox. החלונית נפתחת עם הכרטיסיות Mode ו־Overrides, וכן עם הכרטיסייה Dependencies שמפרטת את כל הרכיבים החסרים. בדיקת התלויות מתבצעת בעת האתחול. לכן יש להפעיל מחדש את Claude Code לאחר התקנת החבילות, אחרת החלונית עדיין תדווח שהן חסרות.

ב־Ubuntu 24.04 ומעלה, מדיניות ברירת המחדל של AppArmor מונעת מ־bubblewrap ליצור את מרחבי השמות של המשתמש הדרושים לו. לכן ארגז החול אינו מצליח להתחיל. בדקו אם הדבר חל על השרת שלכם:

sysctl kernel.apparmor_restrict_unprivileged_userns

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

sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}
EOF
sudo systemctl reload apparmor

הפרופיל חל על bwrap עצמו, ולא על הפקודות שהוא מריץ בתוך ארגז החול. לאחר מכן צמצמו את גבולות הגישה בהגדרות:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

יש להוסיף את הקטע הזה לקובץ .claude/settings.json של הפרויקט, משום ש־. נפתר ל־root של הפרויקט רק מתוך הגדרות הפרויקט. אם תוסיפו את אותן שורות ל־~/.claude/settings.json, אז . ייפתר ל־~/.claude במקום זאת. לכן כלל denyRead ישאיר את קובצי הפרויקט חסומים, וכל פקודה לא תצליח לקרוא את הקוד שהיא אמורה לערוך.

חשוב לדעת מה ההגדרה הזו אינה מכסה. ארגז החול מגביל את Bash ואת תהליכי הצאצא שלו. כלי הקבצים המובנים פועלים בתוך תהליך Claude Code, ושרתי MCP (פרוטוקול הקשר של המודל) ו־hooks הם תהליכים נפרדים שפועלים ללא הגבלה על ה־host. כדי להכניס את כולם לאותה שכבת הגנה, הפעילו את כל תהליך Claude Code בתוך container, מכונה וירטואלית או החבילה @anthropic-ai/sandbox-runtime, שהיא גרסת preview מחקרית מסוג beta בעת כתיבת מדריך זה.

איזה מצב מתאים לכל תצורה?

מאגר יחיד במחשב הנייד האישי

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

VPS משותף

השתמשו ב־auto לכל משתמש, והגדירו אותו בקובץ ~/.claude/settings.json האישי של כל משתמש. יש להפעיל זאת בשרת שבו החשבון שמריץ את Claude Code אינו root ואינו יכול לקרוא את העבודה של משתמשים אחרים. הגדירו את disableBypassPermissionsMode כ־"disable" בתוך /etc/claude-code/managed-settings.json, יחד עם כללי הדחייה שמגינים על נתיבים משותפים. שרת משותף הוא המקרה הברור ביותר שבו bypassPermissions שגוי, משום שגבול הבידוד שעליו מצב זה מסתמך אינו קיים: הדיירים האחרים נמצאים בתוכו.

CI והפעלות ללא השגחה

השתמשו ב־dontAsk עם רשימת allow מפורשת של הפקודות שהמשימה זקוקה להן. דחייה אוטומטית היא מצב הכשל הנכון כאשר איש לא יראה בקשה לאישור. מצב אוטומטי פועל גם ללא אינטראקציה, אך חסימות חוזרות של מנגנון הסיווג מפסיקות הפעלת -p, ולכן משימה שנתקלת בהן נכשלת באמצע, לאחר שחלק מהעבודה כבר בוצע. השאירו את bypassPermissions עבור מכולה או מכונה וירטואלית שאתם בונים מחדש מתמונה, ואל תשתמשו בו במארח שמריץ גם דבר שחשוב לכם.

FAQ

מתי מצב auto הופך לברירת המחדל ב־Claude Code?

החל מ־14 August 2026, עבור הפעלות חדשות בתוכניות Pro, Max ו־Team. בתיעוד מצוין שאפשר להחליף מצב בכל עת, שברירת מחדל שהגדרתם בעצמכם נשארת בתוקף אלא אם תאשרו את בקשת המעבר החד־פעמית, ושברירת מחדל שהארגון מנהל אינה משתנה. בהודעה מצוין שמצב auto נשאר אופציונלי בתוכניות Enterprise ובחשבונות המשתמשים ב־API במהלך החלק הראשון של ההפצה. כדי לבדוק באיזה מצב ההפעלה נמצאת בפועל, הסתכלו בשורת הסטטוס, שבה מופיע ⏵⏵ auto mode on במצב auto.

האם כדאי להשתמש במצב auto או ב־bypassPermissions ב־VPS?

במצב auto, יחד עם גבול בידוד. המסווג בודק כל פעולה לפני שהיא מופעלת, אך בתיעוד מודגש שזהו מנגנון בקרה לכל פעולה ולא גבול בידוד. לכן גם הפעלה ללא השגחה עדיין דורשת container, מכונה וירטואלית או מערכת שאתם מוכנים לבנות מחדש. bypassPermissions מדלג לחלוטין על הבדיקות ומתועד לשימוש בסביבות מבודדות בלבד. Claude Code מסרב להתחיל במצב זה כ־root ב־Linux ומציג את --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons.

כיצד מונעים מכל אדם בשרת להשתמש במצב auto או במצב bypass?

הגדירו את permissions.disableAutoMode ואת permissions.disableBypassPermissionsMode למחרוזת "disable" בתוך /etc/claude-code/managed-settings.json. הגדרות מנוהלות נמצאות מעל כל טווח אחר, ולכן שום קובץ הגדרות של משתמש ושום דגל שורת פקודה אינם יכולים לעקוף אותן. disableAutoMode מסיר את auto ממחזור Shift+Tab ודוחה את --permission-mode auto בעת האתחול. disableBypassPermissionsMode פועל גם מכל טווח, ולכן משתמש יחיד יכול להגדיר אותו בתוך ~/.claude/settings.json שלו.

מדוע ההגדרה defaultMode: "auto" שלי אינה נלקחת בחשבון?

משום שהיא נמצאת בקובץ שגוי. החל מ־Claude Code v2.1.142, ההגדרה defaultMode: "auto" מתעלמת כאשר היא מגיעה מ־.claude/settings.json או מ־.claude/settings.local.json, כדי שמאגר לא יוכל להעניק לעצמו מצב auto באמצעות קובץ הגדרות. ההפעלה מתחילה במצב default ואינה מציגה שגיאה. העבירו את ההגדרה אל ~/.claude/settings.json, ולאחר מכן הריצו את /permissions כדי לאשר מאיזה קובץ הגיע כל כלל פעיל. אם מצב auto עדיין אינו זמין, בדקו את דרישת המודל: מודלים ישנים יותר, כגון Sonnet 4.5, אינם נתמכים אצל אף ספק.