AI Extensions, 8 בנובמבר: מתי אפשר לשתף חיבור MCP בין פרויקטים
OpenCode 2.2.6 מוסיף שיתוף MCP לבחירה. חשבונות, פרוטוקול, היעדר roots והמתנה ללא גבול קובעים את המגבלות.
פתיחת אותו שרת MCP בכמה פרויקטים יכולה להשאיר כמה חיבורים פעילים. OpenCode 2.2.6 מוסיף שיתוף לפי בחירה, אבל שם תצוגה זהה אינו מספיק. התיעוד גם קובע שלחיבור המשותף אין roots, שורשי תיקיות הפרויקטים.
סקירת המקורות של היום
OpenCode v2.2.6 פורסם ב-6 בנובמבר. הגרסה מצהירה על פחות תהליכים והתחלה מהירה יותר בעזרת שיתוף חיבורי MCP, ומוסיפה אפשרויות להרצות מתוסרטות. רישיון MIT מאפשר שימוש חוזר לפי תנאיו. פרסום חדש הוא סימן לתחזוקה, לא הוכחה לבטיחות או להתאמה. לא התקנתי את הגרסה, לא מדדתי זמן הפעלה ולא בדקתי שרת MCP איתה.
מסלול ההגדרה מתחיל בהתקנת OpenCode קיימת, בהגדרות MCP שלה ובאימות של השרת עצמו בעת הצורך. לפי תיעוד MCP, pool כבוי כברירת מחדל.
אילו חיבורים יכולים להשתתף
השיתוף מוגבל לתיקיות באותו שרת OpenCode ולחיבורים המשתמשים בגרסת הפרוטוקול 2026-07-28. כש-pool מופעל בלי protocol מפורש, המשמעות היא auto. שרת שעונה בגרסה ישנה יותר, או חיבור שהוגדר legacy, שומר חיבור נפרד לכל תיקייה.
בחיבור מרוחק חייבים להתאים ה-URL, הכותרות, הגדרות OAuth, החשבון המחובר, הפרוטוקול והזמנים הקצובים. שמות השרתים בדרך כלל אינם חייבים להתאים, אבל כניסות נשמרות לפי שם, ולכן ב-OAuth גם השם חייב להיות זהה. בחיבור מקומי נדרשת התאמה גם של הפקודה, סביבת המשתנים ותיקיית העבודה.
שרת מקומי משותף רק בין תיקיות באותה מכונה, לא תיקיות בתוך workspace. שיתוף בין פרויקטים דורש cwd קבוע. בלעדיו השרת רץ בתיקיית כל פרויקט ו-OpenCode מדפיס אזהרה. שינוי תיקיית העבודה רק כדי להשיג שיתוף עלול להרחיב את מה ששרת רואה, כשבמקור הותר לו לראות פרויקט אחד.
שורשים והרשאות דורשים בדיקה נפרדת
לחיבור משותף אין roots. בקשת קלט מכלי מופיעה בתיקייה שקראה לו. אף כלל אינו מבטיח שהשרת עצמו אוכף הפרדה בין פרויקטים. הייתי בודק קודם את גישתו לקבצים ואת היקף החשבון.
שני פרויקטים המשתמשים באותו חשבון רחב יכולים לעמוד בתנאי ההתאמה, אף שאנשים מצפים לגבולות נתונים שונים. שיתוף אינו מעניק הרשאה חסרה. אני ממליץ להפריד חשבונות staging ו-production ולהשאיר pool כבוי כששרת תלוי ב-roots או במצב משתנה ייחודי לפרויקט, עד לבדיקת התנהגותו. אלה המלצות פריסה, לא טענה שנמצאה חולשה ב-OpenCode.
ה-JSON הבא הוא רישום ביקורת שאינו ניתן להרצה במכוון, לא הגדרת OpenCode תקינה. הוא שומר החלטות בלי סודות ואינו אוכף בידוד.
- שתי תיקיות מבקשות שרת
- השוואת הגדרות והפרוטוקול שסוכם
- שיתוף רק בהתאמה; לחיבור משותף אין roots
{
"server_role": "public-documentation-search",
"pool_requested": true,
"same_account_scope": "review-required",
"requires_project_roots": "review-required",
"fixed_local_cwd": "not-applicable-to-remote",
"protocol_seen": null,
"approved": false
}
לניסוי מאושר השתמשו בשרת זמני ובנתונים סינתטיים. השוו pool-off ו-pool-on בשתי תיקיות, ואז שנו תנאי התאמה אחד. תעדו את הפרוטוקול שסוכם, מספר התהליכים או החיבורים ואת התיקייה שמקבלת בקשת קלט. בדקו שרת שדורש roots. קריאה מוצלחת לכלי אינה מוכיחה בידוד. המאמר מציע ניסוי, ואינו מדווח על תוצאות שבוצעו.
הרצה מתוסרטת עלולה לחכות ללא סוף
אותה גרסה אומרת ש-opencode run ממתין לפקודות shell ברקע, לסוכני משנה ולמשימות תמונה שהבקשה שלו התחילה, ואז מאפשר למודל להגיב לתוצאות לפני היציאה. אין מגבלת זמן מובנית להמתנה. שרת פיתוח או תהליך מעקב קבצים יכולים להשאיר אותה פתוחה עד להפסקה. לפי ההערות, SIGTERM מבטל את הסשן ואת משימות הרקע שלו ומסיים בקוד 143.
ב-CI הייתי מגדיר זמן קצוב חיצוני ותוצר צפוי מראש. תשובה מוכנה בחזית אינה מספיקה אם הקובץ המבוקש תלוי במשימת רקע. נוספה run -w ליצירת worktree חדש של git; אי אפשר לשלב אותה עם --continue או --session. --archived מסתיר הרצות מתוסרטות מרשימות הסשנים ומתיבת הדואר הרגילות, ולכן חשוב יותר לבדוק את יומני המשימה.
היכן הייתי מתחיל
שרת תיעוד לקריאה בלבד עם אותו היקף חשבון בין פרויקטים מתאים לניסוי קטן. שרת שצריך roots דורש בדיקה נפרדת. הייתי בודק את שינוי ההמתנה ב-CI גם בלי שיתוף חיבורים. הערות גרסה ונתוני פופולריות אינם מאשרים את ההתנהגות האמיתית של שרת מסוים.