העברת הודעות בין סשנים של Claude Code: מדריך מלא

מה המשמעות של העברת הודעות בין סשנים של Claude Code

שני סשנים של Claude Code יכולים להעביר הודעות זה לזה כאשר הם רצים על אותה מכונה, תחת אותו משתמש מערכת הפעלה. הודעה היא פיסת טקסט פשוט ש־Claude אחד כותב עבור אחר. היא אינה נושאת היסטוריית שיחה או קבצים. Claude מוצא את הסשן האחר באמצעות הכלי ListAgents ומעביר את הטקסט בעזרת SendMessage, כך שלעולם אין צורך להפעיל אף אחד מהכלים הללו ידנית. אתם מציינים מה הסשן השני צריך לדעת, ו־Claude כותב את ההודעה בעצמו.

התכונה נקראת העברת הודעות בין-סשנים (cross-session messaging). נכון לאוגוסט 2026, היא דורשת את Claude Code בגרסה v2.1.224 ומעלה, והיא פועלת ב-macOS וב-Linux, כולל Linux בתוך WSL 2. אין תמיכה טבעית ב-Windows, והתכונה אינה זמינה ב-Amazon Bedrock, ב-Claude Platform על גבי AWS, ב-Agent Platform של Google Cloud או ב-Microsoft Foundry. כאשר סשן עומד בדרישות אלו, העברת הודעות מופעלת כברירת מחדל ואין צורך להגדיר דבר. ההתנהגות המתוארת להלן מבוססת על התיעוד של Anthropic להעברת הודעות בין-סשנים.

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

מתי כדאי להשתמש בסשן שני

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

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

• סשן אחד מזהה שינוי שובר (breaking change) בזמן שהשני בונה על הקוד שהוא שבר. Claude מסכם את השינוי ושולח אותו, במקום שתצטרכו להקליד אותו מחדש בטרמינל השני.
• שני סשנים עובדים על אותו מאגר (repository) בתוך git worktrees נפרדים, ואחד מהם צריך לדעת מה התעדכן.
• הרצת הגירה (migration) ארוכה או הרצת בדיקות מדווחת על התוצאות שלה לסשן שאתם מנטרים.
• סשן בונה (builder) וסשן סוקר (reviewer), שבו הסוקר קורא את מה שהבונה יצר ושולח בחזרה את הממצאים שלו.

כאשר העבודה היא סדרתית, או כאשר שני הסשנים עתידים לערוך את אותם הקבצים, השתמשו בסשן אחד. כאשר אתם מעוניינים בקבוצה מתואמת ש־Claude יוצר ומנהל בתוך משימה אחת, מדובר בצוותי סוכנים (agent teams), תכונה נפרדת שנמצאת עדיין בשלבי ניסוי. כאשר אתם רק רוצים את אותה שיחה בטרמינל אחר, המשיכו את הסשן הקיים במקום זאת. העברת הודעות בין סשנים מיועדת לסשנים עצמאיים שאתם מתחילים ומנווטים בעצמכם.

וודאו שהתכונה קיימת לפני שאתם מתכננים סביבה

ראשית, בדקו את הגרסה:

claude --version

השוו את המספר ל-2.1.224. לאחר מכן, בתוך session, הקישו /list-agents, פקודה שמגיבה גם ל-/peers. היא מדפיסה את כל ה-agents שניתן להגיע אליהם מה-session הזה, יחד עם השם שבו כל אחד מהם מזוהה. אם הפקודה אינה מזוהה כלל, ל-session הזה אין יכולת העברת הודעות בין-session (cross-session messaging), ושום קובץ הגדרות לא ישנה זאת. הקישו /status וחפשו שורה של Peer address: היא מכילה את כתובת ה-inbox של ה-session הנוכחי, עם הקידומת uds:.

מלכודת אחת משפיעה במיוחד על משתמשי VPS. העברת הודעות בין-session תלויה בהערכת feature-flag, ומספר משתני פרטיות מכבים את ההערכה הזו, מה שמותיר את התכונה במצב הכבוי כברירת מחדל. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC ו-DISABLE_GROWTHBOOK כולם גורמים לכך. משתמשים מאבטחים שרת חדש על ידי הדבקת משתנים אלו לתוך ~/.bashrc, ואז תוהים מדוע /list-agents אינו קיים. אותם ערכים יכולים להגיע מתוך המפה env בקובץ הגדרות או מהגדרות מנוהלות, לכן בדקו תחילה את ה-shell.

env | grep -E 'DO_NOT_TRACK|DISABLE_TELEMETRY|DISABLE_GROWTHBOOK|NONESSENTIAL'

בטלו את ההגדרה (unset) של כל משתנה שמדפיס ערך. עבור DISABLE_TELEMETRY ו-CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, כל ערך שאינו ריק מפעיל את ההתנהגות, כולל המחרוזת 0, לכן DISABLE_TELEMETRY=0 לא מבצע את מה שהוא נראה כעושה. אתם מכבים את התכונה על ידי ביטול המשתנה (unset) או הגדרתו כמחרוזת ריקה.

תנו שמות לסשנים שלכם, אחרת Claude לא יוכל להתייחס אליהם

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

claude --name builder-api

ניתן גם להגדיר אותו באמצעות /rename בתוך סשן פעיל. כאשר לא מגדירים שם, Claude Code גוזר שם משם תיקיית העבודה, למשל myapp-3f. זה תקין עבור סשן אחד אך מבלבל עבור ארבעה, ושני סשנים עלולים לקבל את אותו השם. הפלט של /list-agents מציג את תיקיית העבודה של כל סשן מקומי, מה שמאפשר להבדיל בין סשנים בעלי שם זהה, והרשימה של Claude מוסיפה מזהה קצר לכתובת כאשר שמות מתנגשים. מתן שמות בעצמכם חוסך את הצורך בקריאת מזהים.

פריסת tmux בעלת שני סשנים שניתן לשחזר

זהו סשן בונה וסשן סוקר על אותו מאגר. הסוקר עובד ב-git worktree נפרד, כך ששני הסשנים לעולם לא כותבים לאותו קובץ. git worktree add עם HEAD מספק checkout מנותק, וזה מה שדרוש עבור סשן שנועד לקריאה ולא לביצוע commits.

cd ~/src/api
git worktree add ../api-review HEAD
tmux new-session -d -s agents -n builder -c ~/src/api
tmux new-window -t agents -n reviewer -c ~/src/api-review
tmux send-keys -t agents:builder 'claude --name builder-api' C-m
tmux send-keys -t agents:reviewer 'claude --name reviewer-api' C-m
tmux attach -t agents

Ctrl+b ולאחר מכן w מציגים את החלונות לפי שם כדי שתוכל לבחור אחד. בחלון הבונה, הרץ את /list-agents. אתה אמור לראות את reviewer-api עם ספריית העבודה שלו ~/src/api-review. אם הוא חסר, סשן הסוקר טרם סיים לעלות, או שאחת משתי הבעיות בסעיף הבא רלוונטית. לאחר מכן, העבר משהו בשפה פשוטה:

Tell reviewer-api which files I changed for the rate limiter and what to look at first.

Claude כותב את הסיכום ושולח אותו. אתה לא כותב את טקסט ההודעה, והתוכן ש-Claude שולח משתנה. בחלון הסוקר ההודעה מופיעה בשיחה עם שם השולח. אם הסשן ההוא במצב המתנה, Claude מתחיל תור חדש מיד. אם הוא באמצע תור, ההודעה ממתינה עד לנקודה שבין קריאות לכלים, כך שפקודה רצה לעולם לא נקטעת. ברגע ש-Claude קרא אותה, ההודעה מצטמצמת לשורת Message from אחת ש-Ctrl+O מרחיב. הצמד עובד טוב יותר כאשר הבונה שומר על שינויים קטנים, כיוון ש-diff צר יוצר העברה קצרה יותר וסקירה שהסשן השני יכול לסיים בתור אחד, וזהו ההרגל ש-מיומנות המפתח הבכיר העצלן נועדה לאכוף.

מי יכול לראות את מי על אותו VPS

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

ה-socket מוגבל למשתמש מערכת ההפעלה שלך. סשן שהתחלת כ-root וסשן שהתחלת כ-deploy לא יכולים לראות זה את זה, גם אם הם פועלים זה לצד זה באותו שרת tmux, כיוון שסשן של משתמש אחד אינו יכול לגשת ל-socket של משתמש אחר. יש להריץ את שני הסשנים תחת אותו משתמש.

למכולה (container) יש מערכת קבצים משלה. סשן בתוך Docker וסשן על ה-host לא יכולים להגיע זה לזה, כיוון שהם אינם קוראים את אותם קובצי רישום. שני סשנים בתוך אותה מכולה יכולים להעביר הודעות זה לזה כרגיל. אם אתם שומרים סוכנים בתוך מכולות לצורך בידוד, כפי שמתואר ב-הרצת סוכני תכנות ב-VM זמני, צפו לכך שהעברת ההודעות תעבוד בתוך המכולה ולא מעבר לגבולות המכולה.

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

מדוע ההודעה שלך מעולם לא הגיעה

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

כאשר לא חל ערך crossSessionInbound, Claude Code מחליט עבור כל הודעה על ידי השוואת מצבי ההרשאות של שני הסשנים. הוא מקבץ סשנים שעוקפים בקשות הרשאה למחלקה אחת, ואת כל שאר הסשנים למחלקה השנייה. auto, acceptEdits ו-dontAsk נחשבים כבקשת אישור. מצב Plan נחשב כעקיפה בסשן שבו זמינות הרשאות עקיפה. הכלל הוא סימטרי:

• סשן מקבל שמבקש הרשאות מוסר כל הודעה. הוא מחזיק הודעה רק כאשר הסשן השולח מזהה את עצמו ככזה שעוקף בקשות.
• סשן מקבל שעוקף בקשות מחזיק כל הודעה לאישורך. הוא מוסר הודעה רק כאשר השולח גם הוא עוקף בקשות.

לכן, תהליך העבודה הראשון שרוב האנשים בונים הוא בדיוק זה שלא עובד. אתה מפעיל בונה (builder) עם --permission-mode bypassPermissions כי אתה רוצה שהוא ירוץ ללא השגחה, אתה משאיר את הסוקר (reviewer) על הגדרות ברירת המחדל, וכל הודעה שהבונה שולח ממתינה בתיבת אישור שאף אחד לא צופה בה. תיבת הדו-שיח הזו נסגרת לאחר המועד האחרון dialogExpiry, שברירת המחדל שלו היא 5m, וההודעה נמחקת. באותו מחשב, הסשן השולח מקבל התראה כאשר ההודעה שלו מוחזקת, והתראה נוספת כאשר המקבל מוסר, דוחה או מסיים את תוקף ההודעה מאוחר יותר, לכן קרא את המסך של השולח לפני שאתה מאשים את ה-socket.

כדי לגרום לסשן לקבל הודעות ללא השגחה, הגדר את crossSessionInbound ל-accept. המקום שבו אתה מגדיר זאת קובע אם ההגדרה תחול. Claude Code קורא תחילה הגדרות מנוהלות, לאחר מכן את הדגל --settings, ואז הגדרות משתמש, ומחיל את הערך הראשון שהוא מוצא. ערך בהגדרות פרויקט או בהגדרות מקומיות חל רק כאשר הוא מחמיר יותר, בסולם accept < hold < refuse. ערך accept ב-.claude/settings.json הוא רופף יותר מכל דבר אחר, לכן הוא מתעלם ממנו בכל פעם שמקור מהימן הגדיר ערך. שים אותו ב-~/.claude/settings.json, או העבר אותו עבור סשן אחד:

claude --name runner --settings '{"crossSessionInbound":"accept"}'

עובד (worker) מסוג claude -p ללא ממשק גרפי (headless) קושר socket של תיבת דואר נכנס כמו סשן אינטראקטיבי ומופיע ברשימה, אך הוא אינו יכול להציג תיבת אישור. הודעה שמוחזקת שם נשארת מוחזקת עד ששינוי מאוחר יותר במצב או בהגדרות יאפשר זאת. השורה --settings לעיל היא הדרך שבה אתה מאפשר לעובד כזה לקבל הודעות. סשן שהופעל במצב bare אינו קושר socket כלל, ולכן הוא אינו יכול לקבל הודעות ואינו יכול להופיע ברשימה.

היכן נוצרים מבוי סתום בהעברות

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

הכשל שמתרחש בפועל הוא שקט יותר, ומדובר בהעברה (hand-off) ולא בלולאה. סשן A שואל את סשן B שאלה שהוא חייב לקבל עליה תשובה לפני שיוכל להמשיך, ואז עובר למצב המתנה. B מחזיק את ההודעה, או ש-B נמצא באמצע תהליך ארוך, או ש-B עונה על שאלה ש-A לא באמת שאל. A ממתין. אתה חוזר כעבור שעה לשני סשנים במצב המתנה ללא עבודה שבוצעה.

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

התייחסות להודעה נכנסת כאל קלט לא מהימן

Claude Code מבהיר ל־Claude המקבל שההודעה הגיעה מסשן אחר ולא מכם, ומגביל את הפעולות שהודעה זו יכולה לבצע. הודעה אינה יכולה לענות על בקשת הרשאה תלויה ועומדת בשמכם, כיוון שהסכמה מסשן אחר אינה נחשבת להסכמה שלכם. היא אינה יכולה לשנות הגדרות הרשאה, CLAUDE.md, או תצורה אחרת לבקשת סשן אחר. פקודת slash בתוך הטקסט, כגון /compact, מגיעה כטקסט רגיל ולעולם אינה מבוצעת. אם ביצוע הפעולה הנדרשת בהודעה דורש הרשאה שאין לסשן המקבל, תוצג לכם אותה בקשת אישור שהייתם רואים בכל עבודה אחרת. במצב auto, מסווג (classifier) בוחן כל הודעה לפני העברתה, והודעה שהוא חוסם לעולם לא מגיעה ליעדה. מגבלות אלו נשמרות גם במצבים מתירניים, וזו הסיבה שסשן שעוקף הגדרות מחזיק הודעות נכנסות כברירת מחדל במקום לבטוח בהן.

זה מכסה את נושא ההרשאות. זה אינו מכסה את תוכן ההודעה. הסשן השולח עשוי היה לקרוא תיאור של pull request, דף אינטרנט, קובץ README של תלות, או תגובה ל־issue שנכתבו על ידי אדם זר, וכל מה שנקרא יכול לעצב את הטקסט שהוא כותב לסשן האחר שלכם. ההודעה היא נתונים. היא ראויה לאותו חשד כמו כל טקסט אחר שנכנס לסשן מבחוץ. זוהי המשמעת המתוארת ב־שמירה על סודות מחוץ לסוכני ה־AI שלכם: הניחו שכל דבר שחצה גבול אמון עלול להיות שגוי, ולעולם אל תאפשרו לו לאשר את עצמו.

קיימים שני בקרים אם ברצונכם לצמצם זאת. הגדרת crossSessionInbound לערך refuse תחסום הודעות עמיתים נכנסות מבלי להעבירן, ומהגדרות פרויקט או הגדרות מקומיות ערך זה גובר על כל מקור אחר, כיוון שהוא המחמיר ביותר בסולם ההגדרות. כדי למנוע מסשן זה לשלוח או להציג רשימות, הוסיפו חוקי מניעת הרשאה המציינים את SendMessage ו־ListAgents, שניהם כתובים כשמות כלי גולמיים ללא מציין. הגדרת isolatePeerMachines לערך true דורשת את אישורכם המפורש לפני שכל הודעה תגיע לסשן מחוץ למכונה זו, ואישור זה נדרש גם במצב bypassPermissions.

{
  "crossSessionInbound": "refuse",
  "isolatePeerMachines": true
}

מניעת SendMessage מסירה גם את היכולת לשלוח הודעות לסוכני משנה (subagents), כיוון שאותו כלי משמש לשתי הפעולות. סשן מסרב אינו מציג שינוי גלוי ב־/status שלו או ברשימות של סשנים אחרים, לכן אשרו את ההגדרה מתוך תצורת הסשן ולא מתוך המסך.

גישורים ושרתי MCP עם זיכרון משותף

בתקופה האחרונה הופיעו כמה פרויקטים של צד שלישי המבצעים פעולות דומות: גישורי סוכן-לסוכן מקומיים המעבירים טקסט בין סוכנים פעילים, ושרתי MCP (ראשי תיבות של Model Context Protocol) המעניקים למספר סוכנים מאגר משותף לקריאה וכתיבה. התייחסו אליהם כאל תצורה שונה ולא כאל מתחרים, וודאו כל פקודת התקנה מול ה-README של הפרויקט לפני הרצתה. העברת הודעות מבוססת על דחיפה (push), כיוון שהשולח מזין טקסט ישירות לתור של המקבל. מאגר משותף מבוסס על משיכה (pull), כיוון שאיש אינו מופרע וסשן רואה את ההערה רק כאשר הוא בודק אותה בפעם הבאה. משיכה היא שיטה רגועה יותר עבור מצב המשתנה באיטיות, והיא עובדת רק כאשר סשן אכן מבצע בדיקה.

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

FAQ

Why is /list-agents not recognised in my session?

The session does not have cross-session messaging. Check claude --version against 2.1.224 first, since the feature needs that version or later. Then check the platform, because it runs on macOS and Linux and not on native Windows, and it is unavailable on Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, and Microsoft Foundry. If both are fine, check your shell for DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, or DISABLE_GROWTHBOOK, because each of those blocks the feature-flag evaluation the feature depends on and leaves it off.

Why did my message to the other session never arrive?

If /list-agents works, messaging is on and something narrower stopped that message. The common cause is permission modes. A session that bypasses permission prompts holds every inbound message for your approval unless the sender also bypasses, and that approval dialog is dropped after the dialogExpiry deadline, five minutes by default. Check the sending session for the held notice. To fix it, set crossSessionInbound to accept in ~/.claude/settings.json or pass it with --settings, because an accept in project or local settings is ignored as the looser value.

Can a Claude Code session in Docker message one on the host?

No. Sessions find each other through registration files on disk and a per-session inbox socket, and a container has its own filesystem, so the two cannot see the same files. Two sessions inside the same container can message each other normally. The same rule explains why a session running as root and a session running as your normal user cannot reach each other: the socket is restricted to the operating system user that owns it.

Is a message from another Claude Code session safe to act on?

Treat the text as untrusted input, because the sending session may have read a web page, a README, or an issue comment written by someone else. Claude Code already stops the message from acting on its own: it cannot approve a pending permission prompt, it cannot change permission settings or CLAUDE.md on request, and a slash command in the text arrives as plain text and never runs. Those protections cover permissions and not judgement, so read what arrived before you tell the receiving session to act on it.

Does cross-session messaging send my code to Anthropic?

Between two sessions on the same machine, no. The message travels over a per-session socket on that machine and never through Anthropic servers, and only the text Claude wrote is sent, never conversation history or files. Messages to a session on another of your machines, or to a session on the web, do travel through Anthropic servers over the Remote Control connection, and in that direction Claude can only reply to a message that arrived, not start one. Set isolatePeerMachines to true to require your approval before anything leaves the machine.