העברת הודעות בין סשנים של 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 on AWS, ב-Google Cloud's Agent Platform או ב-Microsoft Foundry. כאשר סשן עומד בדרישות אלו, העברת הודעות מופעלת כברירת מחדל ואין צורך להגדיר דבר. ההתנהגות המתוארת להלן מבוססת על התיעוד של Anthropic להעברת הודעות בין-סשנים.

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

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

התחילו בבחינת העלות. כל סשן הוא מופע (instance) נפרד של Claude עם חלון הקשר (context window) משלו, לכן שני סשנים עולים בערך פי שניים מסשן אחד לאורך אותה תקופת זמן. הודעה שנשלחה נספרת בשימוש בדיוק כמו 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 זה אין יכולת העברת הודעות בין-sessions, ושום קובץ הגדרות לא ישנה זאת. הקישו /status וחפשו שורה של Peer address: היא מכילה את כתובת ה-inbox של ה-session עצמו, עם הקידומת uds:.

מלכודת אחת משפיעה במיוחד על משתמשי VPS. העברת הודעות בין-sessions תלויה בהערכת 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'

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

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

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

claude --name builder-api

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

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

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

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 אינם יכולים להגיע זה לזה, כיוון שהם אינם קוראים את אותם קובצי רישום. שני סשנים בתוך אותה מכולה יכולים להעביר הודעות זה לזה כרגיל. אם אתה שומר סוכנים בתוך מכולות לצורך בידוד, כפי שמתואר ב-הרצת סוכני תכנות במכונה וירטואלית זמנית, צפה לכך שהעברת הודעות תעבוד בתוך המכולה ולא מעבר לגבולות המכולה.

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

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

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

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

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

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

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

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

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

היכן נוצרים מצבי קיפאון (deadlock) בהעברת משימות

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

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

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

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

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

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

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

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

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

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

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

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

FAQ

מדוע הפקודה /list-agents אינה מזוהה בסשן שלי?

הסשן אינו תומך בהעברת הודעות בין סשנים. בדקו תחילה את claude --version מול גרסה 2.1.224, שכן התכונה דורשת גרסה זו או מאוחרת יותר. לאחר מכן בדקו את הפלטפורמה, שכן היא פועלת ב-macOS וב-Linux אך לא ב-Windows מקורי, והיא אינה זמינה ב-Amazon Bedrock, ב-Claude Platform on AWS, ב-Google Cloud's Agent Platform או ב-Microsoft Foundry. אם שני התנאים תקינים, בדקו אם ב-shell שלכם מוגדרים DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC או DISABLE_GROWTHBOOK, כיוון שכל אחד מהם חוסם את הערכת ה-feature-flag שהתכונה תלויה בו ומשאיר אותה כבויה.

מדוע ההודעה ששלחתי לסשן האחר לא הגיעה?

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

האם סשן של Claude Code בתוך Docker יכול לשלוח הודעה לסשן על ה-host?

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

האם בטוח לפעול לפי הודעה מסשן אחר של Claude Code?

התייחסו לטקסט כאל קלט לא מהימן, כיוון שהסשן השולח עשוי היה לקרוא דף אינטרנט, קובץ README או תגובה ב-issue שנכתבו על ידי אדם אחר. Claude Code כבר מונע מההודעה לפעול באופן עצמאי: הוא אינו יכול לאשר בקשת הרשאה ממתינה, הוא אינו יכול לשנות הגדרות הרשאה או CLAUDE.md לבקשת המשתמש, ופקודת slash בטקסט מגיעה כטקסט פשוט ולעולם אינה מורצת. הגנות אלו מכסות הרשאות ולא שיקול דעת, לכן קראו את מה שהגיע לפני שתורו לסשן המקבל לפעול לפיו.

האם העברת הודעות בין סשנים שולחת את הקוד שלי ל-Anthropic?

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