Claude Code ניתוק מרחוק: תסמינים, קריטריונים ופתרונות לשישה סוגי ניתוקים

הדבר הכי מתסכל בהרצת Claude Code מרחוק הוא לא חוסר היכולת להתחבר, אלא להתחבר ואז להתנתק – וכל פעם מסיבה אחרת.

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

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

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

קודם כל תזהו את התסמין: איזה סוג אתם רואים

חיבור מרחוק מורכב משני קצוות: מחשב הפיתוח שעליו רץ Claude Code ←→ ההתקן שממנו אתם צופים. תקלה בכל אחד מהקצוות תתבטא כ"ניתוק", אבל התופעות שונות:

מה שאתם רואים	סביר להניח שזה	קפיצה ל
השיחה נעצרה פתאום, ולאחר התחברות מחדש מגלים שההתקדמות תקועה באותו רגע	שינה / נעילת מסך של מחשב הפיתוח	§1
ניתוק בדיוק ברגע שנכנסים למעלית, עוברים ל-4G, או מחליפים WiFi	החיבור הארוך נקטע	§2
כשסוגרים את הטרמינל המקומי או שהמחשב המקומי נכנס לשינה, החיבור המרוחק נופל מיד	מגבלה מבנית של פתרון שיקוף מסך	§3
מופיע כמחובר, אבל הודעות שנשלחות שוקעות בים ללא כל הודעת שגיאה	חיבור מת למחצה	§4
אפשר להתחבר מחדש, אבל מקבלים שיחה ריקה / ההודעות מהתקופה המנותקת נעלמו	ההתחברות מחדש לא חזרה לשיחה המקורית	§5
כשמתחברים שוב אחרי מספר שעות, השיחה נעלמה	תהליך השיחה נוקה, ואין שחזור מקור	§6

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

1. שינה / נעילת מסך / סגירת מכסה של מחשב הפיתוח

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

למה: אנשים רבים חושבים "מחשב הפיתוח שלי נשאר דולק", אבל מצב שינה מערכתי, שינה עם סגירת מכסה, ונעילת מסך מתוזמנת – כל אלה תולים או הורגים ישירות את תהליך Claude Code. בקצה הצופה רואים "פתאום זה נעצר".

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

פתרון: הגדירו בתוכנית החשמל של מחשב הפיתוח "ללא שינה / ללא שינה בסגירת מכסה". זה הפתרון היחיד שמטפל בשורש – שום פתרון מרחוק לא יכול להציל מכונה שכבר ישנה.

2. ניתוק חיבור ארוך טווח עקב החלפת רשת

תסמין: הניתוק קורה ברגע מאוד מוגדר – נכנסים למעלית, עוברים WiFi ל-4G, או המודם הביתי מתחבר מחדש בחצות.

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

איך לאשר: אם רגע הניתוק מתלאם עם רגע החלפת הרשת שלכם – זהו.

פתרון: את הסוג הזה אי אפשר למנוע, אפשר רק לכסות אותו עם התחברות אוטומטית + ניסיונות חוזרים עם השהיה מתגברת (1s→2s→5s…, כדי לא להציף את השרת בניתוק). SSH חשוף אין לו יכולת כזו – ניתוק הוא ניתוק, צריך לחייג ידנית. כשאתם בוחרים פתרון, זהו קריטריון קשיח.

3. פתרון שיקוף מסך: המחשב המקומי חייב להיות פעיל בחזית

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

למה: ה-Remote Control הרשמי של Anthropic הוא בעצם שיקוף של השיחה שרצה על המחשב המקומי אל הטלפון/הדפדפן. התנאי שלו הוא ש-Claude Code המקומי יישאר פעיל בחזית ומחובר לרשת כל הזמן. ברגע שהמחשב המקומי נופל – לקצה המרוחק אין שום מחזור חיים עצמאי להיאחז בו.

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

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

4. חיבור מת למחצה (half-open): הכי קשה לגילוי

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

למה: כשהרשת מופרעת בשקט (פגת זמן של טבלת NAT, התקן ביניים מאבד מצב, אות חלש שמפיל רק מנות בלי לנתק), שני צדדי ה-TCP עלולים לחשוב שהם עדיין מחוברים – אבל הנתונים בפועל כבר לא עוברים. בלי מנגנון heartbeat, שני הצדדים ישמרו על האשליה הזו לנצח.

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

פתרון: על החיבור להריץ heartbeat (keepalive ping): אם לא מתקבלת שום תגובה מהצד השני תוך זמן מוגדר, קובעים שהחיבור מת למחצה, מנתקים ומתחברים מחדש בעצמכם, במקום לחכות לשווא. קריטריון הפסיקה חייב להיות "לא מתקבלת תשובה", ולא "אין הודעת שגיאה" – חיבור מת למחצה אף פעם לא מדווח על שגיאה.

5. ההתחברות מחדש לא חוזרת לשיחה המקורית / אובדן הודעות

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

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

איך לאשר: לאחר התחברות מחדש, מזהה השיחה השתנה, או שההיסטוריה מתחילה רק מרגע ההתחברות.

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

6. תהליך השיחה נוקה, ואין שחזור מקור (cold recovery)

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

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

איך לאשר: הבעיה מופיעה רק אחרי ניתוק ארוך, לא אחרי ניתוק קצר.

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

רשימת תחקיר (ניתנת ליישום בכל פתרון)

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

1. האם המכונה שרצה את השיחה נכנסה לשינה / ננעלה? → כבו את השינה האוטומטית, קבעו "ללא שינה בסגירת מכסה". (§1)
2. האם רגע הניתוק מתלאם עם רגע החלפת הרשת? → נדרש פתרון עם התחברות אוטומטית + ניסיונות חוזרים, אל תסתמכו על SSH חשוף. (§2)
3. האם כשסוגרים את הטרמינל המקומי, המרוחק מתנתק מיד? → מגבלה מבנית של פתרון שיקוף מסך, צריך לעבור לארכיטקטורת שירות משמר. (§3)
4. תקועים במצב "מופיע כמחובר אבל הודעות לא נענות"? → חיבור מת למחצה, רק בדיקת heartbeat יכולה להציל זאת אוטומטית. (§4)
5. לאחר התחברות מחדש השיחה ריקה / ההודעות חסרות? → צריך "חזרה לשיחה המקורית + הזרמת היסטוריה". (§5)
6. השיחה נעלמת רק אחרי ניתוק ממושך? → צריך שמירה לדיסק + שחזור מקור. (§6)

ביישום לפתרון קונקרטי

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

פתרון מרחוק שלא מתנתק צריך להכיל במקביל: תהליך משמר קבוע בצד מחשב הפיתוח (תואם לשאריות הסיכון של §1 ול-§3), התחברות אוטומטית + ניסיונות חוזרים (§2), בדיקת heartbeat (§4), התחברות חוזרת לשיחה המקורית + הזרמת היסטוריה (§5), ושמירה לדיסק + שחזור מקור (§6).

המערכת של PandaNpc + pandapaw נבנתה על פי שש הנקודות האלה, נקודה אחר נקודה: pandapaw נרשם במחשב הפיתוח כשירות משמר שמופעל עם האתחול (לא חלון טרמינל שאתם חייבים לפתוח ידנית – אם הוא קורס, הוא מורם אוטומטית); בקצה הצופה יש התחברות אוטומטית עם ניסיונות חוזרים; החיבור מריץ heartbeat – אם אין תשובה, הוא קובע שהחיבור מת למחצה ומתחבר מחדש; לאחר ההתחברות מחדש הוא נרשם אוטומטית לשיחה המקורית ומזרים את ההיסטוריה מהתקופה המנותקת; ואפילו אם תהליך השיחה נוקה, שליחת הודעה אחת משחזרת אותו מהדיסק וממשיכה.

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

בור קטן נוסף: כשעובדים מרחוק – אל תיפלו למלכודת החיוב

במהלך תחקיר ניתוקים קל לשנות בהזדמנות זו ל-claude -p (מצב headless), אבל החל מ-15 ביוני 2026 Anthropic שינתה את תעריפי החיוב – headless כבר לא נצרך ממכסת המנוי, אלא אוכל אשראי SDK חודשי קטן; כשהאשראי נגמר, מחויבים לפי שימוש ב-API, ומשתמשים כבדים עלולים לחרוג בקלות מהתקציב. מצב אינטראקטיבי (claude REPL) עדיין נצרך ממכסת המנוי. כשאתם מחליפים פתרון כדי לחקור ניתוקים, שימו לב לא להחליף בטעות גם את שיטת החיוב.