Copilot CLI — הכוח שבטרמינל

למה CLI? כשה-IDE לא מספיק

עד עכשיו עבדתם עם Copilot בתוך VS Code. זה עובד מצוין לרוב המשימות — אבל יש רגעים שבהם ה-IDE הופך למגבלה. כדאי שתזהו את הרגעים האלה, כי הם יגדירו מתי CLI הוא הכלי הנכון:

• Refactoring גדול — רוצים להריץ שינוי על מאות קבצים ולהמשיך לעבוד על קוד אחר בינתיים. ב-VS Code, הסוכן חוסם את העורך. ב-CLI, הוא רץ ברקע
• סשנים מקביליים — צריכים להריץ code review על branch אחד ובמקביל לתכנן פיצ'ר על branch אחר. VS Code תומך בסשן אחד, CLI תומך בכמה
• עבודה על שרת מרוחק — מחוברים ב-SSH למכונה בענן. אין IDE, רק טרמינל. CLI עובד ישירות
• אוטומציה וסקריפטים — רוצים לשלב Copilot בתהליך CI/CD, ב-cron job, או בסקריפט bash. VS Code לא בנוי לזה, CLI כן
• פרויקטים ענקיים — monorepo עם אלפי קבצים. VS Code מאט, CLI רץ בתהליך נפרד בלי להשפיע על שום דבר

Copilot CLI (ממשק שורת הפקודה — Command-Line Interface) הוא הפתרון לכל התרחישים האלה. חשוב להבין: זה לא תחליף ל-VS Code — זה כלי משלים שרץ בתהליך נפרד לחלוטין. הוא לא תופס זיכרון של ה-IDE, לא חוסם את העורך, ויכול לרוץ ברקע בזמן שאתם עושים משהו אחר לגמרי.

מאז שיצא ל-General Availability (זמינות כללית) בפברואר 2026, Copilot CLI הפך מכלי עזר פשוט לסביבת פיתוח אגנטית מלאה — סביבה שמתכננת, בונה, סוקרת, וזוכרת בין סשנים. הכל מהטרמינל. ואם אתם מפתחים שהטרמינל הוא הבית הטבעי שלכם — זה הכלי שחיכיתם לו.

מה כלול? הנה רשימה קצרה של מה ש-CLI יודע לעשות:

• לקרוא ולנתח את כל ה-codebase
• לכתוב קוד, ליצור קבצים ולערוך קבצים קיימים
• להריץ פקודות shell — build, test, lint, deploy
• לסקור שינויי קוד ולתת משוב לפני commit
• ליצור Pull Requests ולנהל issues
• לזכור מה עשיתם בסשנים קודמים ולהמשיך מאיפה שעצרתם
• להתממשק עם שרתי MCP חיצוניים
• לרוץ ב-autopilot בלי צורך באישורים

ההבדל המרכזי נראה בתרשים למעלה: ב-VS Code, סוכן Copilot רץ באותו תהליך (process) עם העורך. כשהסוכן עובד קשה על refactoring מורכב — סורק מאות קבצים, מריץ כלים, מנתח תוצאות — ה-IDE מאט. כתיבת קוד הופכת לאיטית, syntax highlighting מקרטע, ולפעמים VS Code פשוט קופא לרגע.

ב-CLI, הסוכן רץ בתהליך נפרד לחלוטין. הוא משתמש ב-CPU וזיכרון משלו, ב-process משלו, ולא משפיע על שום דבר אחר. אתם יכולים להריץ שלושה סוכני CLI במקביל — אחד על code review, אחד על refactoring, ואחד על כתיבת tests — ובינתיים לעבוד ב-VS Code על קוד אחר לגמרי. בלי האטה, בלי פשרות.

זה מה שהופך את CLI לכלי משמעותי כל כך: הוא לא "Copilot בטרמינל". הוא עוד מימד של עבודה שלא היה אפשרי קודם.

התקנה — Windows, macOS, Linux

Copilot CLI זמין דרך כמה מנהלי חבילות. בחרו את השיטה שמתאימה למערכת ההפעלה שלכם. נקודה חשובה: כל שיטות ההתקנה חוץ מ-npm כוללות עדכון אוטומטי — ה-CLI יתעדכן לגרסה החדשה ביותר בלי שתצטרכו לעשות כלום. זה חשוב כי GitHub מוסיפים פיצ'רים חדשים ל-CLI כל כמה שבועות.

Windows — WinGet

winget install GitHub.CopilotCLI

macOS — Homebrew

brew install --cask copilot-cli

Linux — Shell Script

curl -fsSL https://cli.github.com/copilot/install.sh | sudo bash

כל הפלטפורמות — npm (אפשרות גיבוי)

npm install -g @github/copilot

אימות וקונפיגורציה ראשונית — Auth & Setup

אחרי ההתקנה, הצעד הבא הוא אימות (authentication) — חיבור ה-CLI לחשבון GitHub שלכם. בלי אימות, ה-CLI לא יעבוד — הוא צריך לדעת שיש לכם מנוי Copilot פעיל. התהליך פשוט ולוקח פחות מדקה:

copilot

/model

4 הסוכנים המובנים — מפה מהירה

ב-VS Code, יש לכם Agent Mode אחד שעושה הכל. ב-CLI, Copilot חכם יותר — הוא מאציל אוטומטית לסוכן המתמחה שמתאים למשימה. לא צריך לבחור ידנית (אם כי אפשר). הנה ארבעת הסוכנים:

Copilot בוחר את הסוכן הנכון אוטומטית ברוב המקרים. המנגנון פשוט: הוא מנתח את הפרומפט שלכם ומזהה את הכוונה. אם שאלתם שאלה על הקוד ("How does auth work?") — הוא יפעיל Explore. אם ביקשתם להריץ משהו ("Run the tests") — הוא יפעיל Task. אם ביקשתם תוכנית ("Plan how to add caching") — הוא יפעיל Plan.

אבל תמיד אפשר לכוון ידנית. איך? שתי דרכים:

• פרומפט מכוון — אם רוצים Explore, תפתחו עם "Explain..." או "Where is..." במקום "Add..." או "Fix..."
• פקודות slash — /review תמיד מפעיל Code-review, /plan תמיד מפעיל Plan

ההבדל הגדול לעומת VS Code: שם יש לכם Agent Mode אחד שעושה הכל. ב-CLI, יש התמחות. כל סוכן מותאם למשימה ספציפית, עם כלים ואסטרטגיות שונות. הסוכן Explore לא מנסה לשנות קבצים — הוא ממוקד בלקרוא ולהסביר. הסוכן Task לא מנסה לתכנן — הוא ממוקד בלהריץ ולתקן. זה מה שהופך את הסוכנים ב-CLI ליעילים יותר — כל אחד עושה דבר אחד, טוב.

סוכן Explore — הבנת הקוד בשניות

תארו לעצמכם שנכנסתם לפרויקט חדש עם 200 קבצים. בדרך הרגילה, הייתם פותחים README (אם בכלל יש), מנסים להבין את מבנה התיקיות, קוראים package.json, מחפשים נקודת כניסה, גוגלים מונחים לא מוכרים. התהליך הזה לוקח שעות, ולפעמים ימים — במיוחד ב-legacy codebase עם תיעוד חלקי.

עם סוכן Explore, אתם פשוט שואלים. הוא סורק את כל ה-codebase — כל קובץ, כל תיקייה, כל dependency — ועונה בשפה ברורה. תוך דקה אתם מבינים את הארכיטקטורה שלקח למישהו חודשים לבנות.

סוכן Explore הוא סוכן קריאה בלבד (read-only agent) — הוא לא משנה קבצים, לא מריץ פקודות, ולא כותב קוד. הוא רק קורא, מנתח ומסביר. זה מה שהופך אותו לבטוח לחלוטין — אפשר להפעיל אותו על כל ריפו בלי חשש שישבור משהו. אפילו על ריפו production, אפילו על ריפו שאתם לא מכירים.

הנה דוגמאות לפרומפטים שמפעילים Explore, מהכללי לספציפי:

• What does this project do? — סקירה כללית
• How is authentication implemented? — מיפוי פיצ'ר ספציפי
• Where are the database models defined? — מציאת קבצים
• What are the main dependencies? — ניתוח תלויות
• Draw me the data flow for a user signup — הבנת flow

Explore בפועל — מה קורה מאחורי הקלעים

כשאתם שואלים שאלה שמפעילה Explore, הסוכן עובר תהליך מסודר:

1. סריקת מבנה — קורא את עץ התיקיות ומזהה patterns (src/, tests/, docs/)
2. זיהוי tech stack — בודק package.json, requirements.txt, Cargo.toml ומזהה שפה ו-framework
3. מיפוי entry points — מוצא את נקודות הכניסה (main files, index files, app entry)
4. ניתוח תלויות — מזהה imports ו-exports בין מודולים ובונה תמונה של הקשרים
5. סינתזה — מחבר את הכל לתשובה קוהרנטית

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

סוכן Task — בנייה, בדיקות, הרצה

סוכן Task הוא סוכן הביצוע (execution agent). בניגוד ל-Explore שרק קורא ומסביר, Task עושה דברים — מריץ פקודות אמיתיות: build, test, lint, install. אבל ההבדל בינו לבין פשוט לכתוב פקודה בטרמינל הוא עצום.

כשאתם מריצים npm test בטרמינל ורואים 5 tests שנכשלו, מה קורה? אתם קוראים את הלוג, מנסים להבין למה, פותחים את הקבצים הרלוונטיים, מתקנים, ומריצים שוב. Task עושה את כל הלולאה הזו לבד: הוא מריץ, קורא את הלוג, מזהה את הבעיה, מתקן את הקוד, ומריץ שוב — עד שכל ה-tests עוברים או שהוא מזהה שצריך עזרה.

זה בדיוק מה שהכרתם מ-Agent Mode בפרק 1 — אותה לולאה אגנטית של קלט ← תכנון ← כלי ← בדיקה ← תיקון. רק שעכשיו זה רץ בטרמינל, בתהליך נפרד, ואפשר לתת לו לרוץ ברקע. אתם פותחים טאב חדש וממשיכים לעבוד — Task ירוץ עד שיסיים ויודיע לכם.

דוגמאות לפרומפטים שמפעילים Task:

• Run the test suite and fix any failures — הרצה + תיקון אוטומטי
• Install all dependencies and make sure the project builds — setup
• Run the linter and fix all warnings — ניקוי קוד
• Create a new migration for adding a "role" column to the users table — יצירה + הרצה

סוכן Plan — תכנון לפני ביצוע

הכרתם את Plan Mode (מצב תכנון) מפרק 1 — הרעיון שלפני שמתחילים לכתוב קוד, כדאי לתכנן. ב-CLI, סוכן Plan הוא חזק במיוחד מסיבה אחת: הוא יכול לסרוק את כל ה-codebase לפני שהוא מציע תוכנית. הוא לא מנחש — הוא קורא את הקוד הקיים, מבין את הפטרנים, ובונה תוכנית שמתאימה למה שכבר יש.

למה זה חשוב? כי תוכנית implementation שלא מתחשבת בקוד הקיים היא חסרת ערך. אם הפרויקט שלכם משתמש ב-repository pattern, אתם רוצים ש-Plan ידע את זה ויציע קבצים חדשים שעוקבים אחרי אותו pattern. CLI-Plan עושה בדיוק את זה.

כדי להפעיל Plan Mode, לחצו Shift+Tab בתוך סשן CLI ועברו למצב Plan. שימו לב לאינדיקטור בתחתית המסך (שורת הסטטוס) שמראה באיזה מצב אתם — שלושה מצבים אפשריים: Standard (ברירת מחדל, עם אישורים), Plan (תכנון לפני ביצוע), או Autopilot (ריצה אוטונומית). כל לחיצה על Shift+Tab מעבירה למצב הבא.

מה סוכן Plan עושה:

1. שואל שאלות הבהרה — אם הבקשה לא ברורה מספיק, הוא ישאל לפני שממשיך
2. סורק את הקוד — מזהה קבצים רלוונטיים, תלויות, ודפוסים קיימים
3. בונה תוכנית מפורטת — רשימת שלבים, קבצים שישתנו, סדר ביצוע
4. מחכה לאישור — לא מתחיל ביצוע עד שאישרתם את התוכנית

Plan vs Explore — מה ההבדל?

שני הסוכנים קוראים קוד, אבל המטרה שונה לחלוטין. Explore מנתח את מה שיש — "explain this to me". Plan מתכנן את מה שצריך לבנות — "tell me how to build this". Explore לא משנה כלום ולא מציע שינויים. Plan בונה תוכנית שתוביל לשינויים — ואם אישרתם, הוא יכול לבצע אותם.

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

סוכן Code-review — סקירה לפני commit

סקירת קוד (Code Review) היא אחת המשימות שהכי מתאימות ל-CLI. חשבו על זה: אתם כבר בטרמינל, עובדים על branch, עשיתם כמה שינויים, ורוצים בדיקה מהירה לפני שעושים commit ו-push. בגישה הרגילה, הייתם עושים push, פותחים PR ב-GitHub, מבקשים review מעמית, ומחכים. עם CLI, אתם פשוט מקלידים /review ומקבלים משוב תוך שניות.

פקודת /review מפעילה את סוכן Code-review שעובד עם ארכיטקטורה אגנטית (agentic architecture) — הוא לא רק מסתכל על ה-diff (השינויים). הוא אוסף קונטקסט רחב יותר: סורק את מבנה הריפו, בודק קבצים קשורים, מבין תלויות, ומפנה את תשומת הלב לנקודות שבאמת דורשות תשומת לב. ככה הוא יכול לזהות בעיות שלא נראות כשמסתכלים רק על השורות ששונו — כמו מקרה שבו שיניתם חתימת פונקציה אבל שכחתם לעדכן קובץ אחר שמשתמש בה.

זה אחד הפיצ'רים הכי שימושיים ב-CLI — ואחד שחוסך הכי הרבה זמן. במקום לחכות לעמית שיעשה review, אתם מקבלים "עיניים נוספות" מיידיות, 24/7, על כל שינוי.

שלוש דרכים לסקירת קוד ב-CLI

מה Code-review בודק

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

• באגים — null references, off-by-one errors, resource leaks, race conditions
• בעיות אבטחה — SQL injection, XSS, hardcoded secrets, insecure defaults
• performance — N+1 queries, unnecessary re-renders, missing indexes
• עקביות — האם השינויים עוקבים אחרי ה-patterns הקיימים בפרויקט
• שלמות — האם שכחתם לעדכן tests, documentation, או types
• edge cases — מה קורה עם input ריק, null, או ערכים קיצוניים

כל הממצאים מסווגים לפי חומרה: critical (באגים, אבטחה), suggestion (שיפורים), nit (סגנון). ככה אתם יודעים מה חייב תיקון ומה אופציונלי.

Autopilot Mode — ריצה אוטונומית

במצב רגיל (Standard Mode), Copilot CLI מבקש אישור לפני פעולות משמעותיות — כתיבה לקבצים, הרצת פקודות, מחיקות. זה בטוח, ומומלץ לרוב העבודה. אבל יש רגעים שבהם תהליך האישור הופך למכשול: נניח שביקשתם refactoring על 50 קבצים. כל קובץ דורש אישור — זה 50 לחיצות על "כן". במקום שהסוכן יעבוד 10 דקות ויסיים, אתם עומדים מולו 10 דקות ומאשרים שוב ושוב.

Autopilot Mode (מצב טייס אוטומטי) מסיר את בלמי האישור. תנו ל-Copilot משימה, והוא יעבוד עליה אוטונומית — יכתוב קוד, יריץ tests, יתקן כשלונות, יחזור על הלולאה — עד שהמשימה הושלמה או שנתקע. בלי שום שאלה, בלי שום עצירה.

זה אחד הפיצ'רים החזקים ביותר ב-CLI — וגם אחד שדורש הכי הרבה זהירות. הכוח הזה מגיע עם אחריות: כשאתם נותנים ל-Copilot לרוץ בלי פיקוח, הוא יכול לשנות קבצים, למחוק קוד, ולהריץ פקודות. אם תיתנו לו הוראה לא מדויקת — התוצאה עלולה להפתיע.

איך מפעילים

בתוך סשן CLI, לחצו Shift+Tab כמה פעמים עד שמצב Autopilot מופיע בשורת הסטטוס. הסדר הוא: Standard → Plan → Autopilot → Standard (חזרה למעגל). כשאתם רואים "Autopilot" בשורת הסטטוס — אתם במצב אוטונומי. עכשיו שלחו את הפרומפט שלכם — Copilot יתחיל לעבוד בלי לעצור.

חשוב: אפשר גם לעבור ל-Autopilot באמצע סשן. התחלתם ב-Standard, עשיתם כמה שלבים ידנית, ואז מבינים שהשאר ברור ואפשר לתת ל-Copilot לסיים לבד — לחצו Shift+Tab, עברו ל-Autopilot, ושלחו: Continue with the rest of the plan.

מתי Autopilot עוצר

• המשימה הושלמה — Copilot קובע שהסיום הושג
• שגיאה שלא ניתנת לתיקון — כשהוא לא מצליח לפתור בעיה אחרי מספר ניסיונות
• אתם עוצרים ידנית — Ctrl+C בכל רגע
• מגבלת המשכים — אם הגדרתם מגבלה על מספר הצעדים

ההשלכה על Premium Requests — עלויות

ב-Autopilot, כל צעד שדורש פנייה למודל נספר כ-premium request (בקשה פרימיום). חשוב להבין את מנגנון החיוב כאן:

• מה נספר: כל פרומפט שנשלח למודל — כולל פרומפטים פנימיים ש-Copilot שולח לעצמו כחלק מהלולאה האגנטית
• מה לא נספר: קריאות כלים אוטונומיות (הרצת פקודה, קריאת קובץ, חיפוש) — אלה חינם
• ב-Standard mode: אתם שולחים פרומפט, זה נספר. Copilot עובד, מפעיל כלים (לא נספר), ומחזיר תשובה
• ב-Autopilot mode: אתם שולחים פרומפט ראשון (נספר). אחר כך Copilot שולח פרומפטים פנימיים בלי שאתם שולחים — וכל אחד נספר

בפועל, משימה מורכבת ב-Autopilot — כמו refactoring של 20 קבצים — יכולה לצרוך 20-30 premium requests בקלות. אם אתם קרובים למכסה החודשית, כדאי לעבוד ב-Standard ולאשר כל שלב ידנית.

זיכרון — מה Copilot זוכר ואיך

אחת הבעיות הכי מתסכלות בעבודה עם כלי AI: אתם מסבירים משהו בסשן אחד — "הפרויקט הזה משתמש ב-PostgreSQL, ה-API בנוי ב-FastAPI, והמבנה הוא monorepo" — סוגרים את הסשן, פותחים סשן חדש למחרת, ו-Copilot שוכח הכל. כאילו מעולם לא שוחחתם.

ב-Copilot CLI, המצב שונה לחלוטין. המערכת בנויה עם שלוש שכבות זיכרון שעובדות יחד, מהמקומי ביותר ועד הענן — וכל שכבה מוסיפה מימד של "זכירה" שמשפר את איכות העבודה:

שכבה 1: Session State — מצב הסשן הנוכחי

כל סשן CLI שומר את ההיסטוריה שלו כקובצי JSONL (JSON Lines — שורה אחת לכל אירוע) בתיקייה ~/.copilot/session-state/. מה נשמר? הכל: היסטוריית שיחה, כלים שהופעלו, תוצאות שהתקבלו, תיקונים שבוצעו, והחלטות שנלקחו. זה מאפשר לחזור לסשן ישן ולהמשיך מאיפה שעצרתם.

שתי דרכים לחזור:

• copilot --resume — חזרה לסשן האחרון. הכי נפוץ
• copilot --continue SESSION_ID — המשך סשן ספציפי לפי מזהה. שימושי כשיש כמה סשנים פתוחים

שכבה 2: Cross-session Recall — זכירה בין סשנים

מעבר לסשנים בודדים, CLI בונה גרף קונטקסט מתמשך (persistent context graph) שמחבר מידע מכל הסשנים שלכם. זה לא רק "היסטוריית שיחות" — זה מבנה נתונים שמקשר בין פעולות, קבצים, PRs, ותיקונים.

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

• What files did I change in that PR last week? — מה שיניתי ב-PR שבוע שעבר?
• What was the fix I applied to the auth bug? — מה היה התיקון שהחלתי על באג האימות?
• Show me the tests I wrote yesterday — תראה לי את ה-tests שכתבתי אתמול

וה-CLI יודע לענות — גם אם המידע נמצא בסשן אחר לגמרי. ה-recall הזה עובד אוטומטית: כשאתם שואלים על עבודה קודמת, CLI מזהה שצריך לחפש בהיסטוריה ופונה ל-session store בעצמו. אתם לא צריכים לציין "חפש בסשנים קודמים" — הוא פשוט יודע.

שכבה 3: Copilot Memory — זיכרון ריפוזיטורי

Copilot Memory (זיכרון ריפוזיטורי) היא שכבה שונה מהותית מהשתיים הקודמות. היא מאוחסנת ב-GitHub (בענן, לא על המחשב שלכם) ומשותפת בין כל הממשקים: CLI, VS Code, Coding Agent, Code Review. אם Copilot למד משהו על הריפו שלכם דרך VS Code — הוא יזכור את זה גם ב-CLI, וההפך.

המערכת לומדת אוטומטית מוסכמות של הריפו: סגנון קוד (tabs או spaces? camelCase או snake_case?), דפוסים ארכיטקטוניים (repository pattern? service layer?), תלויות קריטיות (אל תשנה migration files!). כל "זיכרון" מוגבל לריפו אחד ומאומת מול ה-codebase הנוכחי לפני שימוש — ככה מידע ישן ולא רלוונטי לא מזהם את התשובות.

Copilot Memory הופעל כברירת מחדל למשתמשי Pro ו-Pro+ במרץ 2026. אם אתם על תוכנית Business או Enterprise, ייתכן שצריך להפעיל אותו בהגדרות הארגון. אפשר לנהל את הזיכרונות — לראות מה Copilot למד, למחוק זיכרונות שגויים, או להוסיף ידנית — דרך github.com/settings/copilot בלשונית Memory.

הקובץ copilot-instructions.md — הנחיות מפורשות

בנוסף לזיכרון האוטומטי (שלומד לבד), יש הנחיות מפורשות שאתם כותבים ומתחזקים. הקובץ .github/copilot-instructions.md בריפו שלכם נקרא אוטומטית בתחילת כל סשן — גם ב-CLI וגם ב-VS Code. זה המקום לכתוב:

• מוסכמות צוות — סגנון קוד, naming conventions, דפוסי עיצוב
• מגבלות — "אל תשנה קבצי migration", "אל תשתמש ב-any ב-TypeScript"
• העדפות ארכיטקטורה — "השתמש ב-repository pattern", "כל endpoint צריך validation"
• מידע על הפרויקט — tech stack, מבנה תיקיות, נקודות כניסה

הקובץ הזה הוא version-controlled — הוא חלק מהריפו, מנוהל ב-Git, וכל הצוות רואה ומעדכן אותו. זה היתרון על זיכרון אוטומטי: הנחיות מפורשות שכולם מסכימים עליהן, לא ניחושים של AI.

למה הזיכרון חשוב כל כך

ההבדל בין CLI עם זיכרון מוגדר לבין CLI בלי זיכרון הוא דרמטי. בלי זיכרון, כל סשן מתחיל מאפס — Copilot לא יודע את המוסכמות שלכם, לא מכיר את הארכיטקטורה, ולא יודע מה כבר ניסיתם. עם זיכרון, הוא מתנהג כמו חבר צוות ותיק שמכיר את הפרויקט לעומק. ההשקעה ביצירת קובץ copilot-instructions.md ובתחזוקה של הזיכרון משתלמת פי כמה בטיב התשובות שתקבלו.

Auto-compaction — כשהקונטקסט מתמלא

זוכרים את ה-context window (חלון הקונטקסט) מפרק 1? כל שיחה עם Copilot מוגבלת בגודל — המודל יכול "לראות" רק כמות מסוימת של טקסט בכל רגע נתון. הכמות משתנה לפי מודל — Claude Sonnet רואה כ-200K טוקנים, Opus רואה יותר — אבל בכל מקרה יש גבול.

ככל שהסשן מתארך — שולחים פרומפטים, מקבלים תשובות, מריצים כלים — חלון הקונטקסט מתמלא. מה קורה כשמגיעים ל-95% מהקיבולת? Auto-compaction (דחיסה אוטומטית) נכנס לפעולה. זה אחד המנגנונים האלגנטיים של CLI — הוא מאפשר סשנים אינסופיים למעשה, בלי לאבד את ההקשר החשוב. הנה איך זה עובד:

1. יוצר checkpoint — שמירת מצב לפני הדחיסה (לשחזור אם צריך)
2. מכווץ את ההיסטוריה — שומר סיכומי החלטות ותוצאות, מוריד את הפירוט
3. שומר רצפי כלים — כל הכלים שהופעלו ותוצאותיהם נשמרים
4. ממשיך ברקע — לא חוסם את העבודה שלכם

מה שורד את הדחיסה ומה נמחק

כדאי להבין מה auto-compaction שומר ומה הוא מוריד:

• נשמר: סיכומי החלטות ("we chose PostgreSQL because..."), תוצאות כלים, רצפי פעולות, שמות קבצים שנערכו
• נמחק: פירוט מילולי מלא, תוכן קבצים ארוך שנקרא, שגיאות ביניים שתוקנו, הסברים ארוכים שכבר סוכמו

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

פקודות ניהול קונטקסט

שתי פקודות שחשוב להכיר:

• /context — מציג פירוט שימוש בטוקנים: כמה נשאר, כמה כל חלק תופס, ומה ה-breakdown לפי סוג (הודעות, כלים, תשובות)
• /compact — מפעיל דחיסה ידנית, בלי לחכות ל-95%. מועיל כשמרגישים שהתשובות נהיות פחות מדויקות

MCP ב-CLI — שרתים מותאמים בטרמינל

בפרק 5 למדתם להוסיף MCP Servers (Model Context Protocol) ב-VS Code — שרתים חיצוניים שמרחיבים את יכולות Copilot. הידע הזה מועיל ישירות גם כאן: CLI תומך ב-MCP עם אותו פרוטוקול בדיוק, רק עם קובץ הגדרות אחר. מה שאומר שכל שרת MCP שעובד ב-VS Code — עובד גם ב-CLI, ולהפך.

יש גם יתרון ייחודי ל-CLI: שרת GitHub MCP Server מובנה — הוא מותקן מראש ונותן גישה ישירה ל-GitHub API: issues, pull requests, code search, repository metadata. לא צריך להתקין כלום נוסף.

קובץ הגדרות MCP

במקום .vscode/mcp.json, CLI משתמש ב-~/.copilot/mcp-config.json. הפורמט דומה:

{
  "servers": {
    "github": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..."
      }
    },
    "filesystem": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"]
    }
  }
}

ניהול MCP מתוך CLI

אפשר גם להוסיף ולנהל שרתים ישירות מתוך סשן:

סוגי Transport — איך CLI מדבר עם השרת

שלושה סוגי תקשורת — אותם סוגים שהכרתם מפרק 5:

• STDIO (Standard Input/Output) — השרת רץ על המחשב שלכם כתהליך מקומי. CLI מעביר לו הודעות דרך stdin/stdout. הכי נפוץ, הכי פשוט, הכי אמין. זו ברירת המחדל לרוב השרתים
• HTTP (Streamable HTTP) — חיבור לשרת מרוחק דרך פרוטוקול HTTP. מתאים לשרתים שרצים בענן, כמו Azure MCP Server או שרתים מותאמים שמארחים ב-Cloudflare/AWS
• SSE (Server-Sent Events) — גרסה ישנה יותר של תקשורת HTTP שבה השרת שולח אירועים לקליינט. עדיין נתמכת לצורך תאימות אחורה, אבל מסומנת כ-deprecated (מיושנת) בפרוטוקול MCP. אם אפשר, עדיפו HTTP

ההבדל בין MCP ב-VS Code ל-MCP ב-CLI

מבחינת פרוטוקול ויכולות, אין הבדל — אותם שרתים, אותם כלים. ההבדל הוא רק איפה ההגדרות נשמרות:

אם אתם רוצים שרת MCP שזמין בכל פרויקט (כמו GitHub MCP Server) — הגדירו ב-CLI. אם רוצים שרת ספציפי לפרויקט — הגדירו ב-VS Code.

דגלי Scripting — CLI באוטומציה

הכוח האמיתי של CLI — מעבר לעבודה אינטראקטיבית — הוא שאפשר לשלב אותו בסקריפטים, בתהליכי CI/CD, וב-automation. כל מה שאתם עושים ב-CLI בשיחה אינטראקטיבית, אפשר לעשות גם בשורת פקודה אחת שרצה בסקריפט bash, ב-GitHub Action, או ב-cron job. בשביל זה יש דגלים ייעודיים שמתאימים לשימוש שאינו אינטראקטיבי:

דוגמה: סקריפט CI שמריץ code review

#!/bin/bash
# סקירת קוד אוטומטית בתהליך CI
REVIEW=$(copilot -p "Review the staged changes. \
  Report ONLY critical bugs and security issues. \
  Output as JSON with {severity, file, line, message}" \
  --silent --available-tools "read,search")

echo "$REVIEW" > review-report.json

# אם יש בעיות קריטיות — fail the build
if echo "$REVIEW" | jq -e '.[] | select(.severity == "critical")' > /dev/null 2>&1; then
  echo "Critical issues found! Failing build."
  exit 1
fi

שימו לב לקומבינציה: -p (פרומפט בודד ויציאה) + --silent (פלט נקי בלי noise) + --available-tools (רק read ו-search, בלי כתיבה). זה ה-pattern הבסיסי לשילוב CLI באוטומציה: שליטה מלאה על מה הסוכן יכול לעשות, ופלט נקי שאפשר לנתח בסקריפט.

שימושים נפוצים בסקריפטים

• Code review אוטומטי — כחלק מ-GitHub Action שרץ על כל PR
• תיעוד אוטומטי — סקריפט שמפעיל copilot -p "Generate API docs for src/api/" --silent
• בדיקת conventions — לוודא שקוד חדש עוקב אחרי מוסכמות הפרויקט
• סיכום שינויים — יצירת changelog אוטומטי מ-git diff

CLI מול VS Code — מתי להשתמש במה

אחרי שהכרתם את כל היכולות של CLI, שאלה טבעית עולה: אז מתי להשתמש ב-CLI ומתי להישאר ב-VS Code? התשובה: הם לא מתחרים — הם משלימים. מ-VS Code אפשר אפילו לנהל סשנים של CLI דרך ממשק ה-Chat (הסוכן רץ בטרמינל, אתם רואים את הפלט ב-VS Code). הם מיועדים לסוגי משימות שונים.

כלל אצבע פשוט: אם אתם עובדים על קובץ ספציפי ורוצים תוצאה מיידית — VS Code. אם אתם עובדים על פרויקט שלם ומוכנים לחכות כמה דקות — CLI. הנה טבלת ההשוואה המלאה:

תרחישים לדוגמה

כדי שהטבלה תהפוך לפרקטית, הנה תרחישים ספציפיים:

• "צריך לתקן באג בשורה 42" — VS Code. זה שינוי ממוקד בקובץ אחד, inline chat מושלם לזה
• "צריך להוסיף TypeScript types לכל הפרויקט" — CLI. זו משימה שמשנה עשרות קבצים, תיקח זמן, ואין סיבה לחסום את ה-IDE
• "רוצה להבין למה ה-test הזה נכשל" — VS Code. הכל בהישג יד: הקובץ, ה-debug output, ה-stack trace
• "תסקור את כל השינויים שעשיתי היום לפני שאני עושה push" — CLI. /review מהטרמינל, מהיר ויעיל
• "צריך לבנות GitHub Action שמריץ code review אוטומטי" — CLI בלבד. VS Code לא יכול לרוץ בתוך pipeline
• "עובד על שרת מרוחק ב-SSH" — CLI בלבד. אין IDE, יש טרמינל

סיכום מהיר: מתי מה

אם עדיין לא ברור מתי להשתמש ב-CLI ומתי ב-VS Code, הנה הנוסחה הפשוטה ביותר:

• אם המשימה לוקחת פחות מ-5 דקות ונוגעת ב-קובץ אחד או שניים — VS Code
• אם המשימה לוקחת יותר מ-5 דקות או נוגעת ב-יותר מ-3 קבצים — CLI
• אם המשימה צריכה לרוץ בלי IDE (CI, SSH, cron) — CLI תמיד

וזכרו: אפשר להשתמש בשניהם בו-זמנית. VS Code לעריכה מהירה, CLI רץ ברקע על refactoring גדול. אין סיבה לבחור אחד בלבד.