Claude Code: מעבר ל-auto mode כברירת מחדל

מה משתנה ב-auto mode ב-14 באוגוסט 2026

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

ה-תיעוד מציג את השינוי כך:

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

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

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

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

קיימים שישה מצבים. השם בתחילת כל שורה הוא הערך שכותבים בהגדרות או מעבירים ל---permission-mode.

• default: Claude מבקש אישור לפני כל שימוש חדש בכלי. קריאת קבצים בתוך ספריית העבודה עדיין מתבצעת ללא בקשת אישור. ה-CLI (ממשק שורת הפקודה) מגדיר מצב זה כ-Manual ומקבל את manual ככינוי החל מגרסה Claude Code v2.1.200.
• plan: Claude קורא קבצים ומריץ פקודות לצורך חקירה, אך אינו עורך את קוד המקור. עריכות נשארות חסומות עד לאישור התוכנית על ידך.
• acceptEdits: עריכות קבצים מתבצעות ללא בקשת אישור, יחד עם פקודות מערכת הקבצים mkdir, touch, rm, rmdir, mv, cp ו-sed. זה חל רק על נתיבים בתוך ספריית העבודה או ה-additionalDirectories שלך. כל פקודת shell אחרת עדיין תדרוש אישור.
• auto: הכל רץ, כאשר המסווג (classifier) בודק כל פעולה תחילה. חוקי 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.

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

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

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

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

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

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

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

פעולות המותרות כברירת מחדל:

• פעולות קבצים מקומיות בתיקיית העבודה שלך
• התקנת תלויות המוגדרות בקובצי ה-lock או ב-manifests שלך
• בקשות HTTP לקריאה בלבד
• דחיפת קוד (push) לכל ענף במאגר שבו אתה עובד

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

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

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

מיקום המצבים בקובץ 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). ההתאמה הראשונה לפי סדר זה קובעת את התוצאה, וכלל ספציפי יותר אינו גובר על כלל רחב יותר המופיע לפניו. כלל חסימה עבור Bash(aws *) יחסום את aws s3 ls גם אם הגדרת אישור לאותה פקודה בדיוק, לכן לא ניתן להגדיר חריגים לכלל חסימה.

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

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

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

מלכודת אחת כאן נובעת מסיבה מתועדת. 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 מבצע פעולה זהה עבור מצב מעקף (bypass mode), והוא פועל מכל טווח (scope), כך שניתן להגדיר אותו ב-~/.claude/settings.json האישי שלכם כדי למנוע מעצמכם גישה למצב שאינכם רוצים להגיע אליו בשעה 2 לפנות בוקר בשרת פעיל. בשרת שמשמש אנשים נוספים, הציבו את שניהם ב-/etc/claude-code/managed-settings.json במקום זאת, כיוון שקובץ הגדרות משתמש שייך למשתמש, בעוד שקובץ מנוהל אינו כזה.

מדוע מצב אוטומטי בשרת VPS מחייב גבול בידוד

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

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

לכן, השילוב הנכון עבור שרת מרוחק הוא מצב אוטומטי יחד עם סביבה שאתם מוכנים לאבד, ולא bypassPermissions בצירוף תקווה. מצב מעקף (Bypass mode) מתועד עבור סביבות מבודדות בלבד: מכולות (containers), מכונות וירטואליות, או dev containers ללא גישה לאינטרנט, שבהם Claude Code אינו יכול להזיק למערכת המארחת שלכם. שרת VPS שמריץ את מסד הנתונים שלכם ואת ה-reverse proxy אינו עונה על הגדרה זו.

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

Claude Code אוכף את כלל ה-root בעצמו. בלינוקס וב-macOS הוא מסרב להתחיל במצב מעקף תחת 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: אף אחד לא צופה בהנחיה (prompt) בזמן שהסשן רץ.

הגדרת ארגז חול (sandbox) עבור Bash בשרת Ubuntu VPS

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

sudo apt-get install bubblewrap socat

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

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

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 של הפרויקט, כיוון ש־. מתורגם לשורש הפרויקט רק מתוך הגדרות הפרויקט. אם תציבו את אותן שורות ב־~/.claude/settings.json, הרי ש־. יתורגם ל־~/.claude במקום זאת, ולכן חוק ה־denyRead ישאיר את קובצי הפרויקט שלכם חסומים וכל פקודה תיכשל בקריאת הקוד שהיא אמורה לערוך.

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

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

מאגר יחיד על המחשב הנייד שלך

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

שרת VPS משותף

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

סביבות CI וסשנים ללא השגחה

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

FAQ

When does auto mode become the default in Claude Code?

From 14 August 2026, for new sessions on Pro, Max, and Team plans. The documentation adds that you can switch modes at any time, that a default you set yourself stays in place unless you accept the one-time switch prompt, and that a default your organization manages is unchanged. The announcement notes auto mode stays optional for Enterprise plans and for accounts using the API during the first part of the rollout. Check what a session is actually in by looking at the status bar, which reads ⏵⏵ auto mode on in auto mode.

Should I use auto mode or bypassPermissions on a VPS?

Auto mode, paired with an isolation boundary. The classifier reviews each action before it runs, but the documentation is explicit that it is a per-action control and not an isolation boundary, so an unattended run still wants a container, a virtual machine, or a box you are willing to rebuild. bypassPermissions skips the checks entirely and is documented for isolated environments only. Claude Code refuses to start in that mode as root on Linux and prints --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons.

How do I stop anyone on my server from using auto mode or bypass mode?

Set permissions.disableAutoMode and permissions.disableBypassPermissionsMode to the string "disable" in /etc/claude-code/managed-settings.json. Managed settings sit above every other scope, so no user settings file and no command line flag can override them. disableAutoMode removes auto from the Shift+Tab cycle and rejects --permission-mode auto at startup. disableBypassPermissionsMode also works from any scope, so a single user can set it in their own ~/.claude/settings.json.

Why is my defaultMode: "auto" setting ignored?

Because it is in the wrong file. From Claude Code v2.1.142, defaultMode: "auto" is ignored when it comes from .claude/settings.json or .claude/settings.local.json, so that a repository cannot grant itself auto mode by shipping a settings file. The session starts in default mode and prints no error. Move the setting to ~/.claude/settings.json, then run /permissions to confirm which file each active rule came from. If auto mode is still unavailable, check the model requirement: older models such as Sonnet 4.5 are not supported on any provider.