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

מה המשמעות של הרצת Claude Code בצורה מאובטחת על שרת

כדי להריץ את Claude Code בצורה מאובטחת על שרת, השאירו את בקשות האישור להרשאות פעילות, הריצו אותו כמשתמש ייעודי ללא הרשאות מיוחדות, והציבו גבולות ממשיים להרצות ללא השגחה במקום להסתמך על אמון: השתמשו ב-sandbox המובנה, ב-container, או ב-VPS זמני שאינו מכיל מידע רגיש. הדגל --dangerously-skip-permissions מסיר את שלב האישור בין המודל לבין ה-shell שלכם. פשרה זו עשויה להיות סבירה עבור עבודה ללא השגחה, אך רק בתוך גבולות המגבילים את טווח ההשפעה של פקודה שגויה. מדריך זה מסביר מה הדגל משנה בפועל, וכיצד לבנות גבולות אלו בשלבים של בידוד הולך וגובר.

מה Claude Code יכול לעשות בשרת שלך

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

הסיכון הוא אותו משפט שנקרא פעם שנייה. תהליך שמריץ פקודות shell תחת המשתמש שלך יכול לבצע כל פעולה שהמשתמש שלך מורשה לבצע. הוא יכול לקרוא את ~/.ssh/id_ed25519, ~/.aws/credentials, וכל קובץ .env שהמשתמש שלך יכול לפתוח. הוא יכול להריץ curl ולשלוח נתונים לכל מארח (host) שהשרת מסוגל להגיע אליו. הוא יכול להריץ git push --force. לסוכן אין מניעים משלו. הסכנה היא שמשימה תשתבש, או שהטקסט שהוא קרא במהלך העבודה הכיל הוראות שנכתבו על ידי גורם אחר: דף אינטרנט שהוא משך, או הערה ב-issue שהוא התבקש לתקן. למקרה השני קוראים prompt injection, וזו הסיבה ש"המודל בדרך כלל הגיוני" אינו מהווה תוכנית אבטחה. הוראות יכולות להגיע גם ממקור קרוב יותר, כיוון ש-שני סשנים של Claude Code על אותו שרת יכולים לשלוח טקסט זה לזה, והודעה מסשן מקביל היא פשוט עוד טקסט שהסוכן המקבל קורא. עליך לתכנן את ההגנה עבור הרצה כושלת, לא עבור המקרה הממוצע.

מערכת ההרשאות במילים פשוטות

כברירת מחדל, Claude Code מבקש אישור לפני ביצוע פעולות. קריאת קבצים בתוך הפרויקט מתבצעת בשקט, אך עריכת קובץ או הרצת פקודת shell מציגות תחילה את העריכה או הפקודה המדויקת וממתינות לאישור. ניתן לאשר פעולה בודדת, או לאשר סוג פעולה כזה למשך שארית ה-session. אישורים אלו מוגבלים ל-session הנוכחי: יציאה מה-CLI משמעותה שה-session הבא יתחיל שוב בזהירות. עבור כללים שברצונכם לשמור, קובץ ההגדרות מכיל רשימות קבועות של הרשאות (allow), בקשות אישור (ask) ודחיות (deny). לדוגמה: לאפשר את git status, לבקש אישור ב-git push, ולחסום קריאה של .env. כללי דחייה תמיד גוברים. בסיס זה משתנה בעצמו, שכן מצב auto יהפוך לברירת המחדל ב-14 באוגוסט 2026, ולכן כדאי לדעת מה כל מצב הרשאה מאפשר בפועל לפני שתחליטו באיזה מצב יפעל שרת שאינכם יכולים לנטר.

תכנון זה מניח שבן אנוש צופה ב-terminal, ובלפטופ זו אכן המציאות. בשרת, הנקודה היא לרוב שאף אחד לא צופה. אתם מתחילים משימה ארוכה בתוך tmux והולכים לישון, וסוכן שעוצר לשאול שאלה ב-2 לפנות בוקר לא מתקדם עד הבוקר. העצירה עולה כסף וזמן, כיוון ש-session של Claude Code שנמצא בהמתנה מאבד את ה-prompt cache החם שלו והשלב הבא דורש תשלום עבור בנייתו מחדש. זו הסיבה הכנה לכך שאנשים משתמשים ב-flag של דילוג (skip) בשרתים, והבעיה שהיא פותרת היא אמיתית. שאר המדריך הזה עוסק בפתרון הבעיה מבלי לוותר על כל אמצעי ההגנה.

מה משנה הדגל --dangerously-skip-permissions

claude --dangerously-skip-permissions מבטל את שלב האישור. עריכות מתבצעות ללא בקשת אישור. פקודות shell רצות ללא בקשת אישור. גם בדיקות ה-protected-path, שבדרך כלל מגנות על מיקומים רגישים, מדלגות על פעולתן. חוקי ה-deny המפורשים שלכם עדיין תקפים, ומספר פעולות קיצוניות עדיין יעצרו לבקש אישור, אך השורה התחתונה פשוטה: כל מה שהמודל מחליט להריץ, ירוץ.

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

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

ארגז החול המובנה של Claude Code

לפני המדרגות, דעו כי Claude Code כולל כעת ארגז חול (sandbox) ברמת מערכת ההפעלה עבור הפקודות שהוא מריץ, מה שמייתר את רוב הסיבות לשימוש ב־skip flag. בלינוקס הוא משתמש ב־bubblewrap לבידוד מערכת הקבצים, וב־socat כדי לנתב תעבורת רשת דרך proxy. בתוך ארגז החול, פקודה יכולה לכתוב רק לספריית הפרויקט ולספריית זמנית של הסשן, והיא יכולה לגשת לרשת רק דרך proxy שבודק כל דומיין מול רשימת היתרים. בפעם הראשונה שפקודה מבקשת גישה לדומיין חדש, Claude Code יבקש מכם אישור.

הפעילו אותו באמצעות הפקודה /sandbox בתוך סשן. ב-Ubuntu וב-Debian, התקינו תחילה את שתי החבילות הנדרשות:

sudo apt install bubblewrap socat

ב-Ubuntu 24.04 ומעלה, מדיניות ה-AppArmor המוגדרת כברירת מחדל מונעת מ-bubblewrap ליצור את ה-user namespaces הדרושים לו. לוח הבקרה של ארגז החול יתריע כאשר משהו חסר, ותיעוד ה-sandboxing של Claude Code מכיל את פרופיל ה-AppArmor הקצר שמתקן זאת.

לארגז החול יש מצב אישור אוטומטי (auto-allow): פקודות בתוך ארגז החול רצות ללא כל הנחיה, כיוון שהגבול הנאכף מבצע כעת את העבודה שההנחיה נהגה לבצע. פקודות שלא יכולות לרוץ בתוך ארגז החול חוזרות לתהליך ההרשאות הרגיל, כך שפעולות חריגות באמת עדיין ידרשו אישור. עבור רוב תהליכי העבודה בשרת, זהו התחליף הנכון ל-skip flag, כיוון שמתקבלות הרבה פחות שאלות בזכות גבול שנאכף על ידי מערכת ההפעלה, במקום ללא הגנה כלל.

היו מודעים למגבלותיו. כברירת מחדל, פקודה בארגז חול עדיין יכולה לקרוא את רוב מערכת הקבצים, כולל קובצי הרשאות, אלא אם תחסמו נתיבים אלו; ההגדרה sandbox.credentials קיימת בדיוק עבור כך. ה-proxy של הרשת בודק שמות דומיינים ואינו בוחן את התעבורה עצמה, לכן היתר רחב כמו github.com עדיין מאפשר הוצאת נתונים. Docker אינו עובד בתוכו. ארגז החול מעלה את רף האבטחה משמעותית. הוא אינו מהווה גבול בידוד מוחלט, וזו הסיבה שהמדרגות להלן עדיין רלוונטיות.

סולם הבידוד

שלושה שלבים, לפי סדר עולה של בידוד. בחרו בשלב הנמוך ביותר שמתאים למה שרץ על השרת שלכם.

שלב 1: משתמש ייעודי ללא הרשאות (unprivileged user). הסוכן מקבל חשבון משלו, ספריית בית משלו, ספריית פרויקט משלו, וללא הרשאות sudo:

sudo adduser --disabled-password --gecos "" agent

גבולות החשבון מונעים מהסוכן גישה לקבצים שלכם: מפתחות ה-SSH שלכם וכל פרויקט אחר על המכונה. זה גם מאפשר להשתמש בדגל ה-skip, שכן הדגל מסרב לרוץ כ-root. זהו אותו עיקרון כמו הרצת כל שירות כמשתמש ללא הרשאות, מיושם על סוכן. מה שלב 1 אינו מגביל: את הרשת, וכל דבר על המכונה שזמין לקריאה לכל משתמש (world-readable).

שלב 2: מכולה (container). Anthropic מפרסמת devcontainer רשמי שמריץ את Claude Code כמשתמש שאינו root, עם חוקי firewall שמגבילים את המארחים אליהם הסוכן יכול להגיע; מכולה שתבנו בעצמכם תבצע את אותה עבודה. מערכת הקבצים מצטמצמת לנפחים (volumes) שאתם מחברים, והתעבורה היוצאת מצטמצמת למה שחוקי המכולה מתירים. זהו שלב הביניים הנכון כאשר השרת מארח שירותים אחרים שחשובים לכם. המגבלה שלו היא שמכולות חולקות את ה-kernel של המארח, וחיבור (mount) אחד לא זהיר מבטל את הגבול; תנו למכולה את /var/run/docker.sock והיא תוכל להגיע לכל המארח.

שלב 3: VPS ייעודי. השלב החזק ביותר הוא גם הפשוט ביותר: תנו לסוכן מכונה שלמה שלא מכילה שום דבר שחשוב לכם. VPS קטן עולה דולרים בודדים בחודש. הגדירו אותו לפי ספר ההנחיות לעשר הדקות הראשונות ב-VPS חדש, צלמו snapshot של המצב הנקי, ותנו לסוכן לעבוד. שום דבר אחר לא רץ שם. אין מפתח SSH אישי, רק מפתח deploy המוגבל למאגר (repository) אחד בלבד. אין פרטי גישה לענן, אין נתוני ייצור. כאשר הרצה משתבשת, או כשאתם פשוט רוצים התחלה נקייה, שחזרו את ה-snapshot או השמידו ובנו את המכונה מחדש תוך דקות. רדיוס הנזק מוגבל לעלות השכירות. זוהי תצורה שבה --dangerously-skip-permissions מפסיק להיות מפחיד, כי התוצאה הריאלית הגרועה ביותר היא שרת שנבנה מחדש ו-token אחד שבוטל.

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

הגנה על פרטי הזדהות

הכלל החשוב ביותר: המשתמש של ה-agent לא אמור להיות מסוגל לקרוא סודות השייכים לשירותים אחרים.

ספקו את ה-API key ל-agent בלבד. שמרו אותו בקובץ בבעלות המשתמש של ה-agent עם הרשאות 600, וטענו אותו בעת הפעלת ה-shell:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

לאחר מכן, הגבילו את הגישה. ב-Debian וב-Ubuntu, תיקיות בית נוצרות לעיתים קרובות עם הרשאות קריאה לכל משתמש במערכת, לכן יש להדק את ההרשאות: chmod 750 /home/youruser. בדקו את המצב באמצעות ls -ld /home/* ותקנו כל נתיב שהחשבון של ה-agent יכול להציג.

הגדירו טווח לכל token. שימוש ב-GitHub token בעל הרשאות מצומצמות המוגבל למאגר אחד, או ב-deploy key לכל מאגר, מבטיח שדליפת פרטי הזדהות תפגע בפרויקט אחד בלבד ולא בכל החשבון שלכם. אם אתם משתמשים ב-sandbox, הגדירו את הרשאות הגישה כך ש-~/.ssh ו-~/.aws ייחסמו אפילו לקריאה. שמרו את פרטי ההזדהות של סביבת ה-production מחוץ לשרת לחלוטין, שכן ה-agent לא יכול להדליף סוד שלא קיים בו. אם סודות אלו מאוחסנים ב-password manager בניהול עצמי, שמרו אותו על שרת נפרד מה-agent ובצעו לו סקירה עצמאית, כיוון ש-נקודות התורפה של Vaultwarden הן ה-admin token וקובץ הגיבוי ולא ה-vault המוצפן עצמו.

Git הוא רשת הביטחון

כל שינוי שהסוכן מבצע צריך להיות ניתן לסקירה ולביטול, ו-git מספקת את שתי האפשרויות הללו בחינם אם הסוכן עובד על branch:

git switch -c agent/refactor-auth

סקרו את הריצה לאחר מכן באמצעות git diff main...agent/refactor-auth, בצעו merge למה שתקין, ומחקו את ה-branch אם הריצה לא הניבה תוצאות. קל הרבה יותר לקרוא ריצה שנגעה בשלושה קבצים בזמן ארוחת הבוקר מאשר כזו שכתבה מחדש חצי מה-module, וזהו המקרה המעשי עבור מיומנות שמחייבת את הסוכן לבצע את השינוי הקטן ביותר שעובד. הגנו על ה-branch הראשי בצד ה-forge, כך שה-token של הסוכן לא יוכל לבצע אליו push ולא יוכל לבצע force-push לשום מקום. היסטוריית ה-commit משמשת גם כ-audit log למה שקרה בזמן שישנתם, וזה שווה יותר מכל כמות של גלילה ב-terminal.

הרשת היא חלק מטווח הפגיעה

סוכן יכול להריץ את curl. משפט זה מתמצת את כל בעיית ה-egress: כל מה שהסוכן מסוגל לקרוא, הוא מסוגל גם לשלוח למקום כלשהו, וסוכן שחווה הזרקת הנחיות (prompt injection) עלול לעשות זאת. משתמש רגיל ללא הרשאות אינו מגביל זאת כלל, כיוון שכל משתמש יכול להגיע לכל מה שהשרת יכול להגיע אליו. ה-sandbox מגביל זאת לפי דומיין באמצעות ה-proxy שלו. מכולה (container) יכולה להגביל זאת באמצעות חוקי firewall משלה. שרת VPS ייעודי מגביל את מה שקיים מלכתחילה כדי לדלוף, וזו התשובה החסונה ביותר מבין השלוש.

אל תנסו לפתור את בעיית ה-egress באמצעות ufw בלבד. כברירת מחדל, ufw מאפשר את כל התעבורה היוצאת, וכתיבת חוקים יוצאים שעדיין מאפשרים apt, npm, git ו-Claude API היא עבודה מורכבת שנוטה להישבר בשקט. בחרו להציב את הגבול ברמת ה-sandbox, המכולה או המכונה, שם רשימת היתרים (allow list) מבוססת דומיינים או מכונה ריקה מבצעים את אותה עבודה בצורה נקייה.

אם אתם בונים סוכן משלכם מול ה-API במקום להריץ את Claude Code, אותה חשיבה תקפה ללא שינוי. בניית סוכן AI עם Claude על גבי VPS מכסה את הנתיב הזה, והסוכן שלכם ראוי לאותו משתמש ייעודי, לאותם אסימונים (tokens) מוגבלים בהרשאותיהם, ולאותה סביבה חד-פעמית.

הקשחת השרת תחילה

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

FAQ

Is --dangerously-skip-permissions safe to use on a server?

Not by itself. The flag removes every approval prompt, so the first bad command runs the moment the model produces it. It becomes a defensible trade when the blast radius is contained: a dedicated unprivileged user at minimum, and for genuinely unattended work a container or a disposable VPS that holds one project and one scoped token. Never use it on a machine that holds production credentials or data you cannot lose.

Does Claude Code have a sandbox?

Yes. Claude Code ships a built-in sandbox for shell commands, opened with the /sandbox command. It uses bubblewrap on Linux and Seatbelt on macOS, limits writes to the project directory, and routes network access through a proxy that only permits approved domains. Its auto-allow mode runs sandboxed commands without prompts, so it cuts interruptions the way the skip flag does while keeping an OS-enforced boundary. It is not a complete isolation boundary, so pair it with a dedicated user or a dedicated machine for unattended runs.

Why does the skip flag refuse to run as root?

Because root with no permission prompts can modify any file and any service on the system, Claude Code blocks --dangerously-skip-permissions when it runs as root or under sudo on Linux and macOS. The fix is not to fight the check. Create an unprivileged user for the agent and run it there; that account boundary is the first and cheapest layer of containment.

Can Claude Code read my SSH keys and .env files?

It can read whatever the user it runs as can read, and even the sandbox's default policy allows reads of credential paths until you deny them. So run the agent as its own user, keep your own home directory at mode 750 or tighter, deny credential paths in the sandbox settings, and keep production secrets off the machine entirely. A secret the box never held cannot be read or leaked.

What is the safest way to run Claude Code unattended?

A cheap dedicated VPS used only for agent work: hardened in ten minutes, snapshotted clean, running Claude Code under an unprivileged user with the sandbox on, a mode-600 file holding the API key, a per-repository deploy key, and all work on branches you review before merging. If a run goes wrong, you revoke one token and restore the snapshot, and nothing else you own is affected.