Gemini CLI Deleted My Session, So Claude Code Finished the Backup

Posted by Michael S. on April 14, 2026

Update: Gemini CLI Deleted My Session (Twice), So Claude Code Finished the Backup

If you've been following the OneDrive migration saga, here's the latest chapter. It involves Gemini CLI destroying its own conversation history, switching to Claude Code mid-project, and finally getting to the point where I can start deleting files from OneDrive with cryptographic proof that every byte is safely on the backup drive.

What Happened to Gemini

I had a very long Gemini CLI session — 269 messages across 5 sessions, spanning March 23 to April 10. This was the session that built the entire backup system: the quarantine scripts, the cron jobs, the rclone sweeper, all of it.

Then Gemini CLI deleted the session files. Twice.

When I tried gemini --resume latest, it told me no projects exist. The session JSON files in ~/.gemini/tmp/onedrive-personal/chats/ were gone. Empty directory. No Time Machine backups, no APFS snapshots, no Trash copies. On an SSD with TRIM, disk-level recovery is impossible.

What survived: a backup of the logs file (logs.json.invalid_json.*.bak) that contained all 269 of my messages — but none of Gemini's responses. So I had a record of every question I asked and every instruction I gave, but zero record of what was built, why decisions were made, or what the current state of anything was.

Enter Claude Code

I switched to Claude Code (Anthropic's CLI) and asked it to pick up where Gemini left off. The first thing it did was recover that log file and extract it into a readable transcript, so at least I had a reference of what I'd been working on.

Then it had to reverse-engineer the state of the backup by reading the scripts Gemini had written, checking the quarantine queues, and figuring out what was actually backed up versus what was still pending.

The State of the Backup (Worse Than I Thought)

Here's what we found:

  • 82 GB / 127,000 files already on the Seagate — this was the work Gemini had done
  • 283,000 files in the quarantine queues — but most of these were stale entries for deleted node_modules and venv directories
  • No cron jobs active — the crontab was empty
  • The backup scripts existed but weren't running

After filtering out the dead queue entries and running a fresh diff between OneDrive and the backup, we discovered 41,604 files were genuinely missing.

The cp Approach Was Hopeless

The original backup system used cp with gtimeout to copy files. The problem: almost every missing file was "dataless" — it existed as metadata in macOS's FileProvider but the actual content was cloud-only. Each file took 15 seconds to timeout before being marked as failed. With 8 parallel threads, that's about 32 files per minute.

At that rate, just identifying the 41,604 missing files would have taken 22 hours. I killed it after 1 hour when it had processed 2,009 files and copied exactly zero.

rclone Changed Everything

The game-changer was switching to rclone, which talks directly to Microsoft's Graph API, completely bypassing macOS's FileProvider. No dataless timeouts, no permission issues, no FileProvider stalls.

The first rclone run copied 19,350 files in 9 hours, with zero errors. The second pass found only 17 more files — the remaining ~22,000 "missing" files turned out to be phantom FileProvider entries that didn't actually exist in Microsoft's cloud.

The speed varied wildly depending on file size:

  • Small files (Firefox cache, config files): 247 files/minute
  • Medium files (project code, documents): 30 files/minute
  • The Hacks and Leaks directory with multi-GB archives: basically one file every 10-30 minutes

That 24.5 GB 250807711.7z file took about 5 hours to transfer by itself.

Hash Verification Before Deletion

Before deleting anything from OneDrive, I wanted proof. Not just "same file size" — actual cryptographic hash comparison.

rclone supports this: OneDrive exposes a QuickXorHash for every file via the API, and rclone can compute the same hash locally. So we ran rclone check without --size-only, which compares actual file hashes.

This took about 13 hours, mostly because the USB mechanical drive reads at ~2-3 MB/s when computing hashes on large files. The 24.5 GB archive alone took ~3 hours to hash from the USB drive.

Results:

  • 68,608 files hash-verified identical (252 GB)
  • 10,129 files with hash mismatches (need investigation)
  • 553 zero-byte files skipped

Deleting from OneDrive

With the hash-verified list in hand, we're now deleting those 68,608 files from OneDrive via rclone delete. It sends HTTP DELETE requests directly to Microsoft's API — about 530 files per minute, zero errors so far. Should take about 2 hours total.

What's Left

The 10,129 mismatched files need careful handling. These aren't necessarily corrupt — some are files I've been actively editing on the backup drive (like my Journaling directory and my website). For those, the Seagate version is the one I want to keep. For others, the OneDrive version might be newer. This needs to be sorted directory by directory.

Hidden Files Were Missing

One thing both Gemini and the initial Claude Code scans missed: fd (the file finder) skips hidden directories by default. That means .git/ directories inside all 62 project repos, plus .git-notes/, .obsidian/, and .claude/ were never included in the diff or the backup runs.

We caught this and backed up all .git directories (421 files across 62 repos) and the hidden top-level directories (86 files) separately. The .trash/ directory was purged from OneDrive rather than backed up.

The Phantom Files Problem

About 22,000 files appeared in the local OneDrive directory listing (via fd) but didn't actually exist in Microsoft's cloud. When rclone tried to download them, they simply weren't there — rclone found only 17 real files out of 22,062.

These are ghost entries in macOS's FileProvider metadata cache. They show up in ls and fd but don't correspond to real cloud files. They're mostly remnants of deleted node_modules and venv directories. There's no way to "clean" them short of resetting the FileProvider cache entirely.

Lessons Learned

  1. Don't trust CLI tools with your session history. Gemini CLI deleted months of conversation without warning. Export or back up your sessions.
  2. rclone is essential for OneDrive on macOS. The FileProvider is unreliable for bulk operations. rclone bypasses it entirely and talks to the API.
  3. Always hash-verify before deleting. Size matches aren't enough — we found 10,129 files that matched in size but differed in hash.
  4. fd skips hidden files by default. If you're doing a backup audit, remember to check .git/, .obsidian/, and other dotfile directories separately.
  5. USB mechanical drives are painfully slow for hash verification. Budget 10x the time you think it'll take. That 24.5 GB file took 3 hours to hash at USB speeds.
  6. Phantom FileProvider entries are a thing. Don't panic when your file counts don't match — many "missing" files are just stale metadata.

Tools Used

  • Claude Code (Anthropic CLI) — orchestrated the entire recovery and backup completion
  • rclone with onedrive_remote — all transfers and deletions via Microsoft Graph API
  • fd — file discovery (with -H flag for hidden files)
  • Seagate Backup Plus Drive — 1.4 TB external, mounted via Mounty for NTFS write access

Enjoyed this post?

Get notified when I publish something new. No spam, unsubscribe anytime.

← Automating E*TRADE 2FA Extracting Bookmap from ThinkorSwim on Linux →