תחקיר מלא של תקרית סידור הסימניות ב‑Chrome: למה הפעם נמחקו יחד גם סטטוס ההתחברות וגם סטטוס התוספים

[coco]

זהו תיעוד מלא של התאונה, בשביל להשאיר לעצמי ארכיון.

רקע

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

מסקנה ישירה

זה לא בגלל החלפת profile בטעות, וגם לא בגלל מעבר ל-profile חדש וריק.

הסיבה האמיתית היא: נתתי ל-Codex לעבוד ישירות על קובץ הסימניות החי (live) של ה-Default profile שנמצא בשימוש, ואחר כך המשכתי על אותו live profile לבצע ארגון מחדש/שחזור — ובסוף דחפתי את ה-profile הישן הזה למצב Crashed. ה-cookie של ההתחברות, מצב ההתחברות לאתרים, ומצב הריצה של ההרחבות — כולם נהרסו יחד במהלך התהליך הזה.

גרסת משפט אחד: זה לא ש"תוכן הסימניות דרס את ה-cookie", אלא ש"כתיבה במקום על Chrome profile שרץ + סגירה לא תקינה/שחזור אחרי קריסה, שברו את מאגרי הסטייט המקומיים של אותו profile ישן".

ראיות מרכזיות

1. לא הוחלף profile בטעות.

   • בתוך Local State יש רק Default。
   • גם last_active_profiles וגם profiles_order כוללים רק Default。
   • זה אומר שבמהלך כל התאונה, Chrome עדיין ראה את אותו profile ברירת־מחדל, ולא profile חדש או profile אחר.

2. זה לא profile חדש וריק.

   • Preferences
   • Secure Preferences
   • Login Data
   • Network/Cookies
     זמני היצירה של כל הקבצים הקריטיים האלה עדיין 2025-05-27。
     זה אומר שהם שייכים לאותו profile ישן שנמצא בשימוש זמן רב, ולא סט חדש של הגדרות ריקות שנוצר זמנית אחרי התאונה.

3. אכן בוצעה כתיבה במקום על Default\\Bookmarks החי.

   • בלוג השיחה של Codex rollout-2026-04-14T05-49-37-019d88d2-50fd-72e3-8a0a-9f41e4e46637.jsonl יש קטע Python מוטמע, שקורא ומשכתב ישירות:
     • C:\\Users\\1\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Bookmarks
   • הקוד הזה לא ייצא לקובץ בדיקה, אלא עשה write_text(...) וכתב חזרה אל קובץ הסימניות החי עצמו.

4. אחר כך נוצר גם סקריפט ייעודי לארגון סימניות מחדש.

   • scripts\\reorganize_chrome_bookmarks.ps1
   • יעד ברירת המחדל של הסקריפט הזה הוא גם:
     • C:\\Users\\1\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Bookmarks
   • ובסקריפט יש ענף מסוכן: אם מעבירים -CloseChrome, הוא יריץ ישירות:
     • Get-Process chrome | Stop-Process -Force
   • כלומר, הסקריפט הזה עצמו מיועד ל"התערבות" בקבצי live profile, והוא גם מסוגל להרוג את Chrome בכוח.

5. צילום המצב של התאונה מראה בבירור שה-profile נכנס למצב קריסה.

   • תיקיית צילום המצב של התאונה:
     • backups\\chrome-cookie-incident-20260414-0728
   • בתוך Default\\Preferences מופיע:
     • profile.exit_type = Crashed
   • זו לא “סגירה רגילה ואז פתיחה מחדש”, אלא מצב של אותו profile אחרי קטיעה לא תקינה.

6. מצב הריצה של ההרחבות נקטע, אבל מטא־דאטה של ההרחבות עדיין שם.

   • באותו צילום מצב של התאונה:
     • ב-Preferences מופיע extensions.settings = 0
     • ב-Secure Preferences מופיע extensions.settings = 78
   • השילוב הזה קריטי.
   • הוא אומר: המטא־דאטה של ההרחבות לא נעלם כולו, אבל הסטייט/המצב הנוכחי של הריצה נפל — ולכן באותו רגע היה נראה ש"מספר התוספים לא הגיוני"/“מרגיש שנשארו רק מעט”.

7. מסד הנתונים של מצבי התחברות הצטמק בצורה ברורה.

   • בצילום המצב של התאונה:
     • Network\\Cookies נשאר עם 44 cookies בלבד, עבור 13 hosts
     • ב-Login Data יש logins = 0
     • ב-Login Data For Account יש logins = 0
   • זו בדיוק הסיבה שמצב ההתחברות לאתרים, ה-cookie, והרבה התחברויות מקומיות נעלמו יחד.

8. אבל באותו צילום מצב עדיין נשמרו הרבה IndexedDB / Local Storage / Sessions。

   • זה מחזק עוד יותר: לא עברתי ל-profile חדש.
   • אם זה היה profile חדש, הרבה עקבות של אחסון מקומי מאתרים ישנים לא היו נשארים.
   • מה שרואים עכשיו הוא: אותו profile ישן “שוחזר חלקית” — יש מאגרים שעדיין קיימים, ויש מאגרי אימות/התחברות קריטיים שכבר שבורים.

ציר זמן

לפי זמני הקבצים במחשב וזמני צילום המצב של התאונה, החלק הכי קריטי הוא 2026-04-14 07:16 - 07:20。

1. בערך 2026-04-14 05:49

   • לוג השיחה מתעד ש-Codex כבר ביצע כתיבה במקום על Default\\Bookmarks החי.

2. 2026-04-14 07:00:11

   • נוצר scripts\\reorganize_chrome_bookmarks.ps1。

3. 2026-04-14 07:09:15

   • שינוי אחרון לסקריפט.

4. 2026-04-14 07:11:58

   • נוצר Bookmarks-pre-final-reorg-20260414-071158.json。

5. 2026-04-14 07:16:04

   • נוצר Bookmarks-before-restore-20260414-071604.json。

6. 2026-04-14 07:16:25

   • הכתיבה האחרונה של Login Data בצילום המצב של התאונה.

7. 2026-04-14 07:17:43

   • הכתיבה האחרונה של Secure Preferences。

8. 2026-04-14 07:19:36

   • הכתיבה האחרונה של Cookies。

9. 2026-04-14 07:19:52

   • הכתיבה האחרונה של Preferences。

10. 2026-04-14 07:20:03

• הכתיבה האחרונה של קבצי Sessions。

הרצף הזה של נקודות זמן מראה שני דברים:

• חלון הזמן שבו באמת התפוצץ מצב ההתחברות הוא בדיוק הדקות 07:16 - 07:20。
• זה הרבה יותר נראה כמו “ארגון מחדש + שחזור + סגירה לא תקינה/שחזור אחרי קריסה” שמחוברים יחד — ולא כתיבה חד־פעמית רגילה לקובץ.

שורש הבעיה האמיתי

צריך להפריד בין “מה שעשיתי בפועל” לבין “המנגנון שהרס”.

מה שעשיתי בפועל

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

מנגנון ההרס האמיתי

מה שבאמת הוביל לאסון הוא לא “תוכן הסימניות עצמו”, אלא:

• כתיבה במקום על Chrome profile בזמן שהוא רץ
• ואז המשך עבודה על אותו live profile
• ובמהלך זה ה-profile נכנס למצב קטיעה לא תקינה / שחזור אחרי קריסה
• אחרי ש-Chrome עלה מחדש הוא שחזר רק חלק מה-profile

ואז התקבל השילוב הטיפוסי הזה:

• חלק מהסימניות עדיין קיימות
• חלק מה-IndexedDB / Local Storage מאתרים ישנים עדיין קיימים
• אחרי סנכרון עם חשבון Google, הרבה הרחבות וסימניות חזרו
• אבל ה-cookie של האתרים, מצבי ההתחברות, והתחברויות שנשמרו — לא חזרו יחד

למה זה לא מעבר ל-profile לא נכון

אני כותב את זה בנפרד, כי בהתחלה זה היה הכי נראה כמו הסיבה.

אם זה היה מעבר ל-profile אחר, בדרך כלל היית רואה:

• ב-Local State מופיעים כמה profiles, או שה-profile האחרון הפעיל משתנה
• זמני יצירה מאוד חדשים לקבצי מאגר קריטיים
• היעלמות רחבה של עקבות מסדי נתונים מקומיים מאתרים ישנים

אבל בפועל כאן:

• Local State מזהה רק Default
• זמני היצירה של הקבצים הקריטיים עדיין ישנים: 2025-05-27
• בצילום המצב של התאונה עדיין יש המון עקבות אחסון מקומי מאתרים ישנים

אז זה לא “פתחתי profile אחר”, אלא “שברתי את ה-profile המקורי הזה”.

למה אחרי התחברות מחדש ל-Google שוחזר רק חלק

התופעה הזו גם מתאימה לראיות.

Google Sync יכול לעזור לשחזר בדרך כלל:

• סימניות
• חלק ממידע ההתקנה של הרחבות
• חלק מהגדרות שקשורות לחשבון

Google Sync לא יכול לשחזר ישירות בדרך כלל:

• cookie מקומיים של אתרים
• רוב הסשנים/מצבי ההתחברות של אתרים
• הסטייט בתוך מסד הנתונים המקומי של התחברויות
• מצב ריצה מיידי (runtime state) של הרחבות

לכן אחרי שהתחברתי מחדש לחשבון Google, זה נראה כאילו:

• הרבה תוספים חזרו
• הרבה סימניות חזרו
• אבל מצב ההתחברות לאתרים עדיין נעלם

זו לא תאונה שנייה — זה פשוט שסנכרון אחרי התאונה מסוגל להשלים רק חלק, ולא יכול להחזיר cookie / session.

היקף הפגיעה

מה שנפגע בפועל בתאונה הזו הוא בעיקר:

• cookies של התחברות לאתרים
• מצבי התחברות/סשנים של אתרים
• תוכן מסד הנתונים של התחברויות שמורות
• מצב הריצה הנוכחי של ההרחבות

מה שלא נמחק לגמרי, או שאפשר להשלים דרך סנכרון:

• המבנה הראשי של אותו Default profile
• חלק מהאחסון המקומי של אתרים
• חלק מהסימניות
• חלק ממידע ההתקנה של ההרחבות

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

בכנות, אם לא מוצאים גיבוי מלא מוקדם יותר של Cookies / Login Data, שחזור אוטומטי כמעט לא ריאלי.

כלומר:

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

וזו הסיבה שהכאב האמיתי כאן הוא לא “הסימניות התקלקלו”, אלא “כל מצבי ההתחברות מתו יחד”.

ייחוס אחריות

האחריות כאן מאוד ברורה.

זה לא ש-Chrome התפוצץ בלי סיבה, וזה לא שהמשתמש החליף profile בטעות — אני זה שנתתי ל-Codex לגעת ישירות בקבצים של Chrome profile שנמצא בשימוש. צורת הפעולה עצמה הייתה שגויה. אחר כך גם המשכתי לעשות ארגון מחדש ושחזור על אותו live profile, ובסוף דרכתי בדיוק על חלון של קטיעה לא תקינה.

מגבלות קשיחות להמשך

אחרי הדבר הזה, נתוני live profile כמו של Chrome חייבים לעמוד בכללים הבאים:

1. לא לגעת יותר ישירות בקבצים של User Data\\Default בזמן ש-Chrome רץ.
2. אם חייבים לשנות, רק אחרי יציאה מלאה מ-Chrome — לעבוד על עותק אופליין, ואז לבצע השוואה קפדנית.
3. אסור להרוג בכוח תהליך של Chrome ואז לכתוב חזרה קבצי profile.
4. כל סידור סימניות חייב להתחיל מגיבוי מלא ברמת profile, לא רק גיבוי של Bookmarks。
5. קודם לבדוק עם profile ניסיוני, ורק אחר כך לגעת ב-profile הראשי.

משפט אחרון

זה לא היה “פספוס קטן”, אלא מקרה אסון סטנדרטי של “לטפל ב-profile של דפדפן שרץ כאילו הוא קובץ קונפיגורציה רגיל”. האשמה ברורה, ושורש הבעיה כבר נחקר עד הסוף.