פתרון בעיות — Troubleshooting and Common Issues

לפני שנצלול לפרטים — הנה האמת על Troubleshooting: רוב הבעיות ב-Claude Code נובעות מחמש סיבות בלבד. גלישת הקשר, בעיות הרשאות, גרסה לא מעודכנת, הגדרות שגויות, או פרומפט לא מספיק ספציפי. אם תבינו את חמשת התחומים האלה — תפתרו 95% מהבעיות בדקות, לא בשעות.

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

פקודת /doctor — הבדיקה הראשונה שלך

כל רופא מתחיל עם בדיקה כללית לפני שהוא מחפש את הבעיה הספציפית. /doctor הוא בדיוק זה — בדיקת בריאות מקיפה של Claude Code שבודקת את כל המערכת בפקודה אחת. זה הדבר הראשון שתעשו כשמשהו מרגיש לא נכון.

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

מה /doctor בודק?

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

אם /doctor מזהה בעיה, הוא לא רק מדווח עליה — הוא בדרך כלל גם מציע את הפתרון. לדוגמה: אם Node.js בגרסה 16, הוא יגיד "Node.js version 16.x is below the required 18+. Run: nvm install 18." — פתרון copy-paste. אם הכול בסדר, תראו "Clean bill of health" — הכול עובד כמו שצריך.

מתי להריץ /doctor?

יש ארבעה רגעים שבהם /doctor הוא הדבר הראשון שצריך לעשות:

1. כשמשהו מרגיש "שבור": Claude Code לא מגיב כצפוי, פקודות נכשלות, או שהתנהגות השתנתה
2. אחרי עדכון: בכל פעם שמעדכנים את Claude Code — הריצו /doctor מיד אחרי
3. אחרי שינוי הגדרות: ערכתם settings.json או CLAUDE.md? ודאו שלא שברתם משהו
4. פעם בשבוע כבדיקת שגרה: גם כשהכול עובד — בדיקה שבועית תופסת בעיות לפני שהן מפריעות

פקודת /debug — כשClaude מתנהג מוזר

/doctor בודק שהמערכת עובדת. /debug בודק מה קרה כשמשהו השתבש. חשבו על ההבדל ככה: /doctor הוא הבדיקה השנתית אצל הרופא, ו-/debug הוא הצילום אחרי שנפלתם. /doctor אומר "המערכת תקינה", ו-/debug אומר "הנה מה שקרה ברגע שמשהו השתבש".

מתי להשתמש ב-/debug?

השתמשו ב-/debug כשClaude:

• נתן תשובה שגויה: תוצאה שלא מתאימה למה שביקשתם — הוא שינה את הקובץ הלא נכון, או עשה את ההפך ממה שרציתם
• כלי נכשל בשקט: Claude אמר "שיניתי את הקובץ", אבל כשבדקתם — שום דבר לא השתנה. הכלי נכשל בלי הודעת שגיאה ברורה
• התנהגות השתנתה אחרי עדכון: משהו שעבד עד אתמול פתאום לא עובד. אולי עדכון שינה את ההתנהגות
• פלאגינים לא נטענים: Skills או MCP Servers שהיו עובדים פתאום לא מגיבים
• תוצאות לא עקביות: אותו Prompt נותן תוצאות שונות בפעמים שונות — בפעם אחת עובד, בפעם הבאה לא

מה /debug עושה מאחורי הקלעים?

/debug הוא בעצם Skill מובנה (Built-in Skill) — לא סתם פקודה, אלא Agent קטן שיודע לקרוא ולנתח לוגים. הלוגים האלה נמצאים בתיקייה ~/.claude/logs/ ומתעדים כל פעולה שClaude Code עשה: אילו כלים נקראו, באיזה סדר, אילו פרמטרים הועברו, אילו שגיאות חזרו, ומה הייתה ההחלטה בכל שלב. (הכלי /debug נמצא ב-Category של Bundled Skills לצד /simplify, /batch, /review ועוד — כלים מובנים שזמינים בכל סשן.)

כשאתם מריצים /debug, Claude:

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

# מריצים /debug
> /debug

# Claude מנתח את הלוגים ומגלה:
"Edit tool was called on utils.py but old_string was not found in the file.
The file was likely modified between the Read and Edit calls.
Solution: Ask Claude to re-read the file and try again."

> /debug

# Claude מנתח ומגלה:
"MCP server 'github-tools' failed to start. Error: Connection refused on port 3100.
The MCP server process is not running.
Solution: Restart the MCP server, or check if another process is using port 3100."

קריאה ישירה של הלוגים

אם אתם רוצים לקרוא את הלוגים ישירות (במקום דרך /debug), הם נמצאים ב-~/.claude/logs/. כל סשן יוצר קובץ לוג נפרד. הקבצים בפורמט טקסט פשוט ומכילים את כל הפעולות של הסשן.

# צפייה בלוג האחרון
! ls -la ~/.claude/logs/ | tail -5

# קריאת השורות האחרונות
! tail -50 ~/.claude/logs/[latest-log-file]

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

גלישת הקשר — Context Overflow

זו אולי הבעיה הנפוצה ביותר שמשתמשי Claude Code חווים — וגם הכי מבלבלת, כי היא נראית כמו "Claude הפך לטיפש". Claude לא הפך לטיפש. הוא פשוט שכח. בואו נבין למה זה קורה, איך מזהים את זה, ואיך לפתור.

הסימפטומים — איך מזהים גלישת הקשר?

שימו לב לסימנים האלה — הם רמזים ברורים שחלון ההקשר מתמלא:

• סתירות: Claude אומר דבר אחד ואחר כך ההפך — "הקובץ נמצא ב-src/" ואז "הקובץ נמצא ב-lib/" — כי הוא שכח מה קרא
• שכחה: Claude שוכח תוכן קבצים שקרא לפני כמה turns — "איזה קובץ?" כשלפני 5 דקות הוא קרא את הקובץ בעצמו
• אובדן מיקוד: Claude מפסיק לעקוב אחרי המשימה ומתחיל לדבר על משהו אחר, או "ממציא" פתרונות שלא קשורים לבעיה
• תגובות לא קוהרנטיות: תשובות שלא מתחברות למה שנאמר קודם, כאילו Claude נכנס באמצע שיחה שלא שמע
• חזרות: Claude חוזר על אותו דבר שוב ושוב כאילו לא שמע את המשוב שלכם — כי באמת לא "שמע" (הוא שכח)
• פישוט יתר: Claude פתאום נותן תשובות שטחיות ופשטניות, בניגוד לעומק שנתן קודם

הסיבה — למה זה קורה?

Claude Code עובד בתוך חלון הקשר (Context Window) — מרחב מוגבל שמכיל את כל השיחה, כל הקבצים שנקראו, כל ההוראות מ-CLAUDE.md, וכל מה שקרה מתחילת הסשן. חשבו על זה כמו שולחן עבודה פיזי: אם ממלאים אותו בניירות, בשלב מסוים ניירות מתחילים ליפול לרצפה.

ברירת המחדל היא 200K טוקנים. Opus 4.6 עם Max/Team/Enterprise מגיע עד 1M טוקנים — חמש פעמים יותר מקום. אבל גם מיליון טוקנים נגמרים כשקוראים הרבה קבצים גדולים.

כשחלון ההקשר מתמלא, Claude Code מפעיל Auto-Compaction (דחיסה אוטומטית) — מנגנון שמתעורר בסביבות 80-85% תפוסה (תלוי בגודל חלון ההקשר ובגרסה) ומנסה לדחוס את השיחה תוך שמירה על עובדות מפתח. בפועל, המערכת שומרת באפר (buffer) של כ-33K טוקנים כדי להבטיח מקום לתשובה הבאה. הבעיה? הדחיסה האוטומטית לא תמיד יודעת מה חשוב לכם. היא עלולה לדחוס פרט קריטי שאתם צריכים — למשל, שם משתנה ספציפי, או מספר שורה שצריך לתקן.

הפתרונות — מהמהיר ביותר לעמוק ביותר

/compact "preserve: migrating from PostgreSQL to MySQL, tables: users (id, name, email), orders (id, user_id, total), products (id, name, price). Current task: writing the orders migration script. Already completed: users table migration."

מניעה — איך להימנע מגלישת הקשר

הטיפים האלה יאריכו את חיי הסשנים שלכם משמעותית:

1. עקבו אחרי /context באופן קבוע — בדקו את אחוז התפוסה כל 10-15 turns. הפקודה מראה כמה טוקנים בשימוש, כמה אחוז מההקשר תפוס, ומה הגודל המקסימלי שלכם (200K או 1M). הפכו את זה להרגל
2. עשו Compact פרואקטיבי ב-50-60% — אל תחכו שהמערכת תדחוס אוטומטית ב-80%. Compact מוקדם = שליטה טובה יותר
3. קראו חלקי קבצים, לא קבצים שלמים — "קרא שורות 1-50 מ-app.py" במקום "קרא את app.py". קובץ של 500 שורות = ~5K טוקנים מיותרים אם צריכים רק פונקציה אחת
4. שמרו CLAUDE.md קצר וממוקד — CLAUDE.md נטען בכל turn, אז כל מילה מיותרת שם עולה בטוקנים. 50 שורות של CLAUDE.md מיותר = אלפי טוקנים מבוזבזים על פני סשן שלם
5. פצלו משימות ארוכות — במקום "בנה את כל האפליקציה" ← "בנה את ה-API" ← "בנה את ה-UI" ← "חבר ביניהם"

בעיות הרשאות — Permission Denied

"Permission Denied" — שתי מילים שמסוגלות לגרום לתסכול אדיר. "למה Claude לא יכול לקרוא את הקובץ הזה? הוא קרא אותו אתמול!" אבל ברגע שמבינים שיש רק שלוש סיבות אפשריות, הפתרון הופך לפשוט. תמיד אחת משלוש.

סיבה 1: Sandbox חוסם — הסיבה הנפוצה ביותר

מערכת ה-Sandbox (ארגז חול) של Claude Code מגבילה גישה לקבצים ולרשת כברירת מחדל. זה טוב לאבטחה — מונע מ-Claude Code לגשת לקבצים רגישים או לשלוח נתונים לשרתים לא מורשים. אבל לפעמים זה חוסם משהו שאתם לגיטימית צריכים.

מערכת ה-Sandbox ב-Claude Code משתמשת ב-Seatbelt (ב-macOS) או ב-bubblewrap (ב-Linux) ברמת מערכת ההפעלה. זה אומר שהבידוד אמיתי — לא רק בדיקת הגדרות, אלא מניעה אמיתית ברמת ה-OS.

הפתרון: בדקו את .claude/settings.json — במיוחד את permissions.allow ו-permissions.deny:

// .claude/settings.json
{
  "permissions": {
    "allow": [
      "Read(*)",
      "Edit(*)",
      "Bash(npm *)",
      "Bash(git *)",
      "Bash(python3 *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(sudo *)"
    ]
  }
}

הוסיפו את הכלי או הנתיב הספציפי שאתם צריכים ל-allow. חשוב: אל תפתחו הכול — היו ספציפיים. "Bash(*)" זה יותר מדי. "Bash(npm test)" זה בדיוק מספיק.

שימו לב ש-Wildcards עובדים כאן: Bash(npm *) מאפשר כל פקודת npm, mcp__github__* מאפשר כל פעולה של MCP GitHub. וכשיש קונפליקט בין allow ל-deny, deny תמיד מנצח.

סיבה 2: הרשאות מערכת הפעלה

לפעמים הבעיה היא לא ב-Sandbox אלא ברמת מערכת ההפעלה — הקובץ שייך ל-root או למשתמש אחר, או שאין לכם הרשאת כתיבה על הקובץ.

# בדקו הרשאות — מי הבעלים ומה ההרשאות?
! ls -la path/to/file

# תוצאה אפשרית:
# -rw-r--r-- 1 root root 1234 Mar 23 10:00 config.json
# ↑ הקובץ שייך ל-root — אתם לא יכולים לערוך אותו

# פתרון — שנו בעלות:
! chown $USER path/to/file

# או שנו הרשאות:
! chmod 644 path/to/file     # קריאה+כתיבה לבעלים, קריאה לכולם
! chmod 755 path/to/directory # קריאה+כתיבה+ריצה לבעלים

סיבה 3: בידוד רשת

Claude Code מגביל גישת רשת לדומיינים מורשים בלבד דרך שרת Proxy פנימי. אם אתם צריכים גישה ל-API חיצוני, לשרת מקומי, או לדומיין ספציפי — ייתכן שתצטרכו להוסיף אותו ל-allowlist בהגדרות ה-Sandbox.

אם אתם על macOS ומשתמשים בכלי CLI שכתובים ב-Go (כמו terraform או kubectl), ייתכן שתצטרכו להפעיל sandbox.enableWeakerNetworkIsolation בהגדרות — כי Seatbelt לא תמיד עובד נכון עם binaries של Go.

קפיצות עלות — Cost Spikes

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

חמשת גורמי העלות העיקריים

חמשת הפתרונות — שליטה מעשית בעלויות

1. עקבו אחרי עלות עם /cost ו-Statusline: הסתכלו על ה-Statusline בתחתית המסך — הוא מראה את עלות הסשן בזמן אמת. הריצו /cost אחרי כל turn מורכב
2. הורידו Effort למשימות שגרתיות: /effort low לדברים פשוטים (שאלות, חיפושים), /effort medium לרוב העבודה, /effort high רק לבעיות מורכבות שבאמת דורשות חשיבה עמוקה
3. השתמשו ב-Sonnet או Haiku לפעולות פשוטות: /model והחליפו למודל זול יותר. לא צריך Opus כדי לענות על "מה שם הקובץ הזה?" — Sonnet מספיק ועולה פי 10 פחות
4. עשו Compact באופן קבוע: פחות הקשר = פחות טוקנים לעיבוד מחדש בכל turn. Compact ב-50% במקום 80% חוסך טוקנים על כל turn שאחריו
5. קראו חלקי קבצים: "קרא שורות 100-150 מ-app.py" במקום "קרא את app.py". אם צריכים רק פונקציה אחת — אל תטענו את כל הקובץ

תגובות איטיות — Slow Responses

Claude מסתובב כבר דקה וחצי ולא עונה. מה קורה שם? למה לפעמים התגובה מגיעה תוך 3 שניות ולפעמים תוך דקה? בואו נבין את חמש הסיבות הנפוצות ואת הפתרונות.

הסיבות והפתרונות — טבלת ההתמצאות

הקומבינציה האיטית ביותר והמהירה ביותר

הקומבינציה הכי איטית: Opus + High Effort + חלון הקשר מלא (80%+). זה עולה הרבה וגם לוקח הרבה זמן. כל turn עם הקומבינציה הזו יכול לקחת 30-90 שניות.

הקומבינציה הכי מהירה: Sonnet + Low Effort + חלון הקשר ריק. תגובה ב-2-5 שניות.

למשימה ממוצעת, הקומבינציה הטובה ביותר: Opus/Sonnet + Medium Effort + חלון הקשר מתחת ל-50%. תגובה ב-5-20 שניות, איכות מצוינת.

בעיות התקנה ועדכונים

בעיות התקנה הן מתסכלות כי הן מונעות מכם אפילו להתחיל לעבוד. הנה הבעיות הנפוצות ביותר עם פתרונות copy-paste — שמרו את הסעיף הזה, תצטרכו אותו.

בעיה 1: גרסת Node.js ישנה מדי

אם התקנתם Claude Code דרך npm, הוא דורש Node.js 18 ומעלה. אם יש לכם גרסה ישנה יותר, תקבלו שגיאה כבר בהפעלה. שימו לב: מאמצע 2025 קיים גם Native Installer (מתקין מקורי) שלא דורש Node.js כלל — זו הדרך המומלצת כיום להתקנה ב-macOS, Windows ו-Linux. אבל אם אתם על npm — הנה איך לבדוק ולתקן:

# בדקו את הגרסה
node --version

# אם מתחת ל-18 — עדכנו:

# עם nvm (מומלץ — כי מאפשר לנהל כמה גרסאות):
nvm install 18
nvm use 18

# או עם package manager (Ubuntu/Debian):
sudo apt update && sudo apt install nodejs

# או עם Homebrew (macOS):
brew install node

טיפ: אם אתם עובדים על כמה פרויקטים, nvm הוא הכלי הנכון. הוא מאפשר לכם להחזיק כמה גרסאות Node בו-זמנית ולעבור ביניהן בפקודה אחת. ביצועים: Node.js 22 LTS (היציב האחרון) מציע שיפורי ביצועים ותאימות מלאה עם Claude Code — שווה לשדרג אם אתם עדיין על 18.

בעיה 2: שגיאות npm Permission (Linux/macOS)

בעיה קלאסית ב-Linux — npm מנסה לכתוב לתיקייה גלובלית שצריך root בשבילה, ומקבלים EACCES error:

# פתרון 1: sudo (מהיר אבל פחות נקי)
sudo npm install -g @anthropic-ai/claude-code

# פתרון 2: שינוי prefix (נקי יותר, מומלץ לטווח ארוך)
mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global

# הוסיפו ל-PATH ב-.bashrc או .zshrc:
export PATH=~/.npm-global/bin:$PATH

# טענו מחדש:
source ~/.bashrc   # או source ~/.zshrc

# ואז התקינו:
npm install -g @anthropic-ai/claude-code

פתרון 2 נקי יותר כי הוא לא דורש sudo — כל ההתקנות הגלובליות יישבו בתיקייה הביתית שלכם.

בעיה 3: PATH לא מוגדר (Windows)

אחרי התקנה ב-Windows, לפעמים הטרמינל לא מוצא את claude. הפתרון הפשוט ביותר: סגרו את הטרמינל ופתחו מחדש. Windows צריך לטעון מחדש את ה-PATH אחרי התקנה גלובלית.

אם זה עדיין לא עוזר — הוסיפו את תיקיית npm הגלובלית ל-PATH ידנית. בדרך כלל היא נמצאת ב-%APPDATA%\npm.

בעיה 4: עדכון נכשל

# נסו עדכון רגיל קודם:
npm update -g @anthropic-ai/claude-code

# אם נכשל — הסירו והתקינו מחדש:
npm uninstall -g @anthropic-ai/claude-code
npm install -g @anthropic-ai/claude-code

# ודאו שהעדכון הצליח:
claude --version

# ואז בדקו שהכול תקין:
# (בתוך Claude Code)
/doctor

בעיה 5: Version Mismatch — גרסה לא מסתנכרנת

לפעמים claude --version מראה גרסה ישנה גם אחרי עדכון. הסיבה הנפוצה: יש שתי התקנות של Claude Code — אחת גלובלית ואחת מקומית, והמקומית עוקפת את הגלובלית.

# מצאו איפה Claude Code מותקן:
which claude
# או ב-Windows:
where claude

# אם יש שתי תוצאות — הסירו את המיותרת

בעיה 6: Firewall ארגוני

ארגונים רבים חוסמים גישה לאתרים חיצוניים. Claude Code צריך גישה לשני דומיינים:

• registry.npmjs.org — להתקנה ועדכונים
• api.anthropic.com — לתקשורת עם ה-API של Claude

בקשו מצוות ה-IT לפתוח את שני הדומיינים האלה. אם אי אפשר — שאלו על Proxy פנימי שדרכו אפשר לגשת. אם גם זה לא אפשרי — Claude Code דרך Bedrock (AWS) או Vertex (Google Cloud) עוקפים את הצורך ב-api.anthropic.com.

כשClaude נתקע — אסטרטגיות Reset

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

שש מדרגות ה-Reset — The Reset Ladder

בעיות ספציפיות ופתרונות

Checkpoints ו-/rewind — מכונת הזמן שלכם

אם יש תכונה אחת ב-Claude Code שצריך להכיר לפני שמתחילים לעבוד — זו מערכת ה-Checkpoints. חשבו עליה כמו Save Points במשחק מחשב. כל פעם שאתם שולחים Prompt, Claude Code שומר תצלום מלא של המצב — גם השיחה וגם הקבצים. אתם לא צריכים לעשות כלום — זה קורה אוטומטית.

איך Checkpoints עובדים?

• אוטומטי לגמרי: Checkpoint נוצר בכל פרומפט שאתם שולחים — בלי שום פעולה מצדכם, בלי הגדרות, בלי כלום. פשוט עובד
• כולל קבצים: לא רק השיחה נשמרת — גם מצב הקבצים. אם Claude שינה קובץ ואתם עושים rewind, הקובץ חוזר למצב שלו לפני השינוי
• נשמר 30 יום: יש לכם חודש שלם כדי לחזור לכל נקודה. זה לא נמחק בסוף הסשן
• מבוסס Git: Checkpoints משתמשים ב-git מאחורי הקלעים, אז הם יעילים מבחינת מקום אחסון — רק ההבדלים (diffs) נשמרים
• לא מפריע: יצירת Checkpoint לוקחת מילישניות ולא מאטה את העבודה
• מגבלה חשובה — Bash: Checkpoints עוקבים אחרי שינויים שנעשו דרך כלי Edit ו-Write בלבד. קבצים שנוצרו או שונו דרך פקודות Bash (למשל ! echo "x" > file.txt או ! sed -i ...) לא נכללים ב-Checkpoint — ולא ניתן לשחזר אותם עם /rewind. זו סיבה נוספת לעשות git commit לפני ניסויים

שלוש דרכים לחזור אחורה

# הדרך המהירה — שנייה אחת:
# לחצו Escape פעמיים
# ← הכול חוזר — השיחה *וגם* הקובץ!

# או, אם רוצים לחזור יותר אחורה:
> /rewind
# ← מופיעה רשימה של Checkpoints עם תיאור
# ← בחרו את הנקודה שלפני ה-Refactor
# ← הכול חוזר לאותו מצב בדיוק

# נקודת ההתחלה — הכול שמור אוטומטית כ-Checkpoint

# גישה A:
> "עשה refactor לפונקציה עם Strategy Pattern"
# ← Claude מבצע שינויים
# ← בדקו את התוצאה... לא מושלם

# חזרה להתחלה:
> /rewind
# ← בחרו את ה-Checkpoint שלפני הRefactor

# גישה B:
> "עשה refactor לפונקציה עם Factory Pattern"
# ← Claude מבצע שינויים אחרים
# ← זה יותר טוב! נשאיר.

מתי להשתמש ב-Checkpoints?

• Claude עשה שינוי לא רצוי: Escape x2 — חזרה מיידית, כאילו שום דבר לא קרה
• רוצים לנסות גישה אחרת: /rewind לנקודת ההתחלה ← נסו גישה חדשה
• השיחה הלכה לכיוון לא טוב: /rewind לנקודה שבה הכול היה בסדר
• ניסוי: עשו את הניסוי, ואם לא עבד — /rewind כאילו שום דבר לא קרה. אפס סיכון
• לפני שינוי מסוכן: אתם יודעים שClaude הולך לעשות משהו גדול? ה-Checkpoint כבר נשמר. נסו בראש שקט

לקבל עזרה — כשבאמת נתקעים

ניסיתם /doctor, ניסיתם /debug, ניסיתם את כל מדרגות ה-Reset — ועדיין תקועים. מה עכשיו? לא להילחץ. יש מספר ערוצים שיכולים לעזור, מהמהיר ביותר ועד העמוק ביותר.

ערוצי עזרה — מהמהיר לעמוק

איך לדווח באג טוב עם /bug

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

1. מה עשיתם: "ביקשתי מ-Claude לערוך את הקובץ utils.py, שורה 45"
2. מה ציפיתם שיקרה: "שהפונקציה calculate_total תשתנה לכלול מע"מ"
3. מה באמת קרה: "Claude מחק את כל הקובץ" / "שגיאה: [הודעת שגיאה מלאה]"
4. מה ניסיתם: "ניסיתי /debug — הציג X. ניסיתי /doctor — הכול נקי. ניסיתי Ctrl+C ופרומפט חדש — אותה בעיה"
5. סביבה: "Claude Code v2.1.81, Node 20, macOS 14.3, Opus 4.6"

ככל שתהיו יותר ספציפיים, כך הפתרון יגיע מהר יותר. "זה לא עובד" הוא דיווח גרוע. "Edit tool silently fails on files larger than 5000 lines when old_string contains Hebrew characters" הוא דיווח מצוין.

מניעה — הרגלים שמונעים בעיות

הפרק הזה עד כה עסק ב"כבאות" — איך לכבות שריפות. הסעיף הזה עוסק במניעת שריפות. שבע הרגלים פשוטים שמונעים 90% מהבעיות. כל הרגל לוקח שניות — ביחד הם חוסכים שעות.

הרגל 1: התחילו בתיקייה הנכונה — תמיד

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

# בתחילת כל סשן — פעולה ראשונה:
! pwd
# ← ודאו שאתם בתיקיית הפרויקט, לא ב-Home או במקום אחר

אם אתם עובדים על כמה פרויקטים, הפעילו Claude Code מתוך תיקיית הפרויקט: cd ~/projects/my-app && claude.

הרגל 2: Git לפני ניסויים — רשת ביטחון כפולה

Checkpoints הם רשת ביטחון מצוינת, אבל git נותן רשת ביטחון נוספת שעובדת גם מחוץ לClaude Code. לפני שאתם מבקשים מClaude שינוי ניסיוני:

! git add .
! git commit -m "save point before experiment"

# עכשיו אפשר לנסות כל דבר בביטחון
# אם צריך לחזור: git checkout -- .

הרגל פשוט: Commit → Experiment → Review → Commit/Revert. ארבעה שלבים שמונעים אובדן עבודה.

הרגל 3: עקבו אחרי עלות והקשר — כל 10-15 turns

הגדירו לעצמכם תזכורת מנטלית: כל 10-15 turns, בדקו שני דברים:

• /cost — כמה עולה הסשן? האם זה בטווח הסביר?
• /context — כמה הקשר תפוס? אם מעל 50% — Compact!

זה לוקח 5 שניות וחוסך הפתעות בסוף היום.

הרגל 4: Compact פרואקטיבי — ב-50%, לא ב-80%

אל תחכו לדחיסה האוטומטית ב-80%. עשו Compact ב-50-60% עם הוראות ספציפיות שמגידות לClaude מה לשמור:

/compact "preserve: working on feature X in file Y, bug is in function Z, next step is testing"

למה 50% ולא 80%? כי ב-50% אתם שולטים. ב-80% המערכת שולטת — וייתכן שהיא תדחוס מידע שאתם צריכים.

הרגל 5: CLAUDE.md מעודכן ורזה

CLAUDE.md שלא מעודכן הוא גרוע יותר מ-CLAUDE.md שלא קיים — כי הוא מטעה את Claude עם מידע ישן. ו-CLAUDE.md ארוך מדי הוא בזבוז טוקנים, כי הוא נטען בכל turn. בדקו אותו אחת לשבוע:

• האם כל ההוראות עדיין רלוונטיות?
• האם יש מידע שהתיישן?
• האם אפשר לקצר — לשמור רק את מה שבאמת משפיע?

הרגל 6: עדכנו Claude Code באופן קבוע

פעם בשבוע, הריצו את השלישייה:

# 1. עדכון
npm update -g @anthropic-ai/claude-code

# 2. בדיקת גרסה
claude --version

# 3. בדיקת בריאות (בתוך Claude Code)
/doctor

עדכונים מביאים תיקוני באגים, שיפורי ביצועים, ותכונות חדשות. Claude Code מוציא עדכונים תכופים — ב-2026 לבד יצאו עשרות עדכונים.

הרגל 7: סקרו הרשאות חודשית

אחת לחודש, פתחו את .claude/settings.json ושאלו:

• האם יש כאן הרשאות שכבר לא צריך? (הסירו אותן — פחות הרשאות = יותר אבטחה)
• האם יש הרשאות שחסרות ומאטות אותי? (הוסיפו אותן)
• האם ה-deny list מעודכנת? (ודאו שפקודות מסוכנות עדיין חסומות)

מילון מונחים — Troubleshooting

Frameworks להחלטות

שגרת עבודה — תחזוקה ומניעה

תרגילים מעשיים

בדוק את עצמך — האם עברת את פרק 11?

צ'קליסט — סיכום פרק 11

• אני יודע להריץ /doctor לבדיקת בריאות מלאה של המערכת
• אני יודע להריץ /debug כשClaude מתנהג באופן בלתי צפוי
• אני מבין את ההבדל בין /doctor (בדיקת מערכת) ל-/debug (ניתוח סשן)
• אני מזהה סימפטומים של גלישת הקשר (Context Overflow)
• אני יודע לעשות /compact ידני עם הוראות ספציפיות
• אני עוקב אחרי /context ועושה Compact ב-50-60%
• אני מזהה את שלושת סוגי ה-Permission Denied ויודע לפתור כל אחד
• אני עוקב אחרי עלויות עם /cost ויודע לשלוט ב-Effort ו-Model
• אני יודע להשתמש ב-Checkpoints — Escape x2 ו-/rewind
• אני מכיר את שש מדרגות ה-Reset — מניסוח מחדש ועד --bare
• אני יודע לדווח באג עם /bug ולחפש עזרה בערוצים הנכונים
• אני עושה git commit לפני ניסויים
• אני מעדכן Claude Code כל שבוע ומריץ /doctor אחרי עדכון
• אני סוקר הרשאות ב-settings.json אחת לחודש
• אני זוכר את מפל ה-Troubleshooting: Prompt ← /debug ← /doctor ← /bug

סיכום הפרק