שרתי ה-MCP שלכם אוכלים בשקט את הדיסק של המק

אחד ממחשבי המק שלנו מריץ סוכני קוד מבוססי AI בלילה, ללא השגחה. ב-3 באוקטובר 2026 הוא נעצר באמצע עבודה עם ENOSPC — אין מקום בדיסק — כשיותר מ-417 GB היו בשימוש מתוך דיסק של 460 GB. אף אחד לא התקין כלום בכוונה. אף אחד לא הוריד כלום בכוונה. המכונה פשוט עשתה את העבודה הרגילה שלה.

עד שניקינו אותו, 50 GiB מהדיסק היו ~/.cache/uv: 3,286,436 קבצים, שברובם נכתבו על ידי שרתי MCP. עוד 14 GB היו ~/.npm/_npx, מאותה סיבה.

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

למה שרתי MCP ממלאים דיסק שאף אחד לא מסתכל עליו

רוב שרתי ה-MCP בפייתון מורצים עם uvx <package>. uvx הוא כלי מצוין: הוא מאתר את הגרסה המתאימה של החבילה, בונה סביבה מבודדת ומריץ אותה תוך שניות, בלי להתקין כלום ביד. המחיר הוא איפה הוא שומר את הסביבה הזאת — ב-cache הגלובלי של uv, ש-uv לעולם לא מנקה מעצמו. כל מה שהוא מוריד ופורס נשאר שם עד שמשהו מוחק אותו.

uv כן מבצע דה-דופליקציה: הרצה חוזרת של אותו שרת באותה גרסה משתמשת במה שכבר ב-cache, כך שריסטארט לא עולה כלום. ה-cache גדל כשמגיעות גרסאות חדשות — uvx <package> בלי נעילת גרסה מושך כל שחרור חדש, ושלושה כלים שונים שנועלים שלוש גרסאות שונות של אותו שרת מחזיקים שלוש סביבות. תוסיפו כמה שרתים, כמה קליינטים וכמה חודשים — והגרסאות הישנות עדיין כולן שם.

בצד של npm זה אותו סיפור: שרתי MCP שמורצים עם npx נוחתים ב-~/.npm/_npx, וגם אותו שום דבר לא מנקה.

למה הניקוי המתבקש לא פשוט עובד

הפתרון המתועד הוא uv cache clean. על מכונה שבה שרתי MCP רצים, הוא נחסם: ה-cache נעול על ידי תהליכי ה-uvx החיים. הדבר שממלא את הדיסק הוא גם הדבר שמחזיק את הנעילה. בגלל זה זה הופך למטלה שדורשת נוכחות ולא למשהו שעבודה לילית עושה לבד — צריך קודם לעצור את השרתים, וזה אומר שכל קליינט AI על המכונה מאבד את כלי ה-MCP שלו עד שמפעילים אותו מחדש.

עוד שתי מלכודות שנפלנו בהן בדרך, כדי שאתם לא תצטרכו:

• uv cache size הוא ניסיוני ועובר על כל העץ. על 3.29 מיליון קבצים זה לוקח דקות ונראה תקוע. גם du -sh. מודדים פעם אחת, לא בכל שלב.
• uv cache prune בטוח להרצה בזמן שהשרתים חיים — הוא מוחק רק אובייקטים שאינם נגישים. לא בדקנו אותו על ה-cache הזה; הוא מה ששמים ב-cron.

הפלייבוק, עם המספרים האמיתיים

קודם שחררנו את ה-cache של npm (זה קנה את המקום שאפשר להמשיך לעבוד), ואז הרצנו את הבלוק הבא עבור uv. המכונה היא המק מלמעלה; ה-shell הוא zsh. הפלט מובא עם נתיבים מקוצרים, בלי שורות האזהרה "experimental" של uv, ועם הערה אחת שנוספה.

לפני שמדביקים: pkill -f uvx מתאים את עצמו לשורת הפקודה המלאה של כל תהליך. בהדבקה לשל אינטראקטיבי זה בסדר; בתוך סקריפט או עטיפת zsh -c '…' ששורת הפקודה שלה עצמה מכילה את המחרוזת, הוא הורג את העטיפה. הריצו קודם pgrep -fl uvx ותראו מה אתם עומדים לעצור.

echo "== BEFORE =="; uv cache size; df -h / | tail -1; du -sh ~/.cache/uv
pkill -f uvx; sleep 2
uv cache clean
echo "== AFTER =="; uv cache size; df -h / | tail -1; du -sh ~/.cache/uv

== BEFORE ==
53771051008                                        # uv cache size, bytes = 50.1 GiB
/dev/disk3s3s1   460Gi   12Gi   54Gi   18%   /
 50G    /Users/…/.cache/uv
Clearing cache at: .cache/uv
Removed 3286436 files (42.6GiB)
== AFTER ==
0
/dev/disk3s3s1   460Gi   12Gi   67Gi   15%   /
du: /Users/…/.cache/uv: No such file or directory

3,286,436 קבצים נמחקו, 42.6 GiB לפי uv. df החזיר מתוכם 13 Gi (מ-54 ל-67 Gi פנויים); לא רדפנו אחרי הפער — גם snapshots מקומיים של APFS וגם קבצים משותפים עם סביבות קיימות יכולים להסביר אותו, ואף אחד מהם לא נמדד.

תופעת לוואי אחת שכדאי לתכנן: pkill -f uvx עוצר את שרתי ה-MCP של כל קליינט AI על המכונה. מפעילים את הקליינטים האלה מחדש אחרי הניקוי.

מה שינינו כדי שזה לא יחזור

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

1. בדיקה מקדימה בכל עבודה ארוכה. לפני שאצווה מתחילה, קוראים df ומסרבים לרוץ מתחת לרצפה — אצלנו 30 GiB פנויים. עבודה שמתה ב-ENOSPC באמצע הורסת את התוצאות של עצמה; עבודה שמסרבת להתחיל לא עולה כלום.
2. uv cache prune לפני כל אצווה. בטוח בזמן שהשרתים רצים, חינם, ומונע מאובייקטים לא-נגישים להצטבר.
3. uv cache clean מתוזמן ובנוכחות — פעם בחודש מספיק — עם השרתים עצורים. אותו דבר ל-~/.npm/_npx.
4. מודדים על כרטיס, לא בראש. בלוק הלפני/אחרי שלמעלה יושב עכשיו על הטיקט שעקב אחרי התקלה, עם שם המכונה עליו. מי שייתקל ב-ENOSPC על המכונה הזאת בפעם הבאה ימצא את המתכון בחיפוש אחד במקום להמציא אותו מחדש בשתיים בלילה.

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