What is cloud sync git corruption?
Cloud sync git corruption occurs when a cloud synchronization service like iCloud Drive, Dropbox, OneDrive, or Google Drive modifies the contents or structure of a .git directory. These services are designed to sync regular files between devices, but a .git directory is a transactional database with strict internal consistency requirements. Cloud sync engines cause corruption through several mechanisms: renaming .git to resolve conflicts (iCloud), creating conflict copies of internal files (Dropbox), dehydrating objects to cloud-only placeholders (OneDrive), and locking files mid-operation (Google Drive). The result ranges from silent data loss to a complete inability to use the repository. Over 2.75 billion people use these cloud sync services, and none of them warn users about the git incompatibility.
In April 2026, my Mac Mini got bricked. Years of development infrastructure, gone. So I opened my older laptop to recover what I could from iCloud sync. That is when I found something worse than a dead machine.
No warning. No error dialog. No recovery path. I ran a git command and got fatal: not a git repository. iCloud had silently renamed my .git folders.
$ cd ~/Projects/patent-filings
$ git status
fatal: not a git repository (or any of the parent directories): .git
$ ls -la
drwxr-xr-x 12 josh staff 384 Apr 14 09:12 .
-rw-r--r-- 1 josh staff 0 Apr 14 09:12 Icon\r
drwxr-xr-x 8 josh staff 256 Apr 13 22:47 git 2That last line is the one that stops you cold. .git became git 2. That single rename makes the entire repository invisible to git.
When I investigated, I discovered something worse than a one-time failure. This is a systematic problem affecting every major cloud sync provider. And nobody is talking about it.
Your project folder has a hidden tracking system called git. It keeps a record of every change you make to your code, your writing, your designs. Everything. Think of it like a detailed journal that remembers every version of your work.
Cloud sync services like iCloud, Dropbox, and OneDrive break this tracking system. They do not mean to. But they treat your project's journal like a normal folder full of normal files, when it is actually a structured database that requires specific rules to work.
What goes wrong
Cloud sync sees your project's tracking folder and tries to "help" by syncing it between devices. But syncing a database file-by-file is like photocopying a book one random page at a time and expecting it to still make sense. Pages get renamed, reordered, or replaced with blank placeholders. The result: your project history is destroyed.
In April 2026, I lost years of development work in a single afternoon. My Mac Mini died, so I opened my laptop to recover from iCloud. Instead of finding my projects, I found that iCloud had silently renamed the hidden tracking folders in every single one of them.
The error I saw
When I tried to open my project, the system said: "fatal: not a git repository." That means the project no longer recognizes its own history. All the tracking data was still on my computer, but it had been renamed in a way that made it invisible.
There was no warning before it happened. No pop-up. No email. No undo button. The sync service that was supposed to protect my files is the thing that destroyed them.
Key takeaway
If your project folder is inside iCloud Drive, Dropbox, OneDrive, or Google Drive, your project's change history is at risk right now. This affects over 2.75 billion users across these four services, and none of them warn you about it.
Filesystem-level failure mode affecting any agent or pipeline that assumes .git directory integrity. The .git directory is a transactional object store with strict consistency invariants: content-addressed blobs, ref pointer atomicity, index file locking, and pack file checksums. Cloud sync engines violate this consistency model through rename, dehydration, concurrent access, and file injection.
Failure taxonomy
Rename corruption: iCloud appends conflict suffixes to the .git directory itself. Git requires the exact path .git (or GIT_DIR env). Any rename produces fatal: not a git repository with exit code 128. No process-level signal. No filesystem event that standard monitoring catches.
Index corruption: Dropbox opens .git/index concurrently, bypassing .lock file protocol. Result: fatal: index file corrupt. Corrupted index means staging area is unreadable. Any CI/CD step that runs git add or git diff --cached fails silently or with non-deterministic output.
Object dehydration: OneDrive Files-On-Demand replaces .git/objects/ content with cloud-only placeholders. Git reads a placeholder expecting a zlib-compressed object and gets garbage. Pack index CRC checks fail. git fsck reports missing objects with no path to recovery.
File injection: Google Drive injects desktop.ini and metadata files into .git/ on Windows. Builds that glob .git/** pick up unexpected entries. Symlink and hardlink support is absent, breaking worktrees and submodule structures.
Systemic implication
This is not a user error class. It is an environmental failure class. Any agent framework that clones repos to local disk, any CI/CD runner that caches workspaces on developer machines, any local dev environment that touches a synced directory inherits this failure mode. The attack surface is the default filesystem layout of macOS (Desktop + Documents synced to iCloud) and Windows (OneDrive-backed user folders). 2.75 billion users across four providers. Zero provider-side mitigations. Zero tooling-side detection in any major agent framework.
In April 2026, this failure mode destroyed a production development environment. The .git directory was renamed from .git to git 2 by iCloud's fileproviderd daemon. No exit code. No log entry. No filesystem event observable by FSEvents or inotify. The rename was only discoverable by manual ls -la inspection after git commands began failing.
Detection gap
Standard health checks (git status, git fsck) only work when .git exists at the expected path. If the directory has been renamed, these commands exit with code 128 before any check runs. An agent or pipeline would need a pre-git filesystem probe (verifying .git directory existence and naming before invoking any git operation) to detect this class of failure. No major framework implements this probe today.
What actually happened
iCloud's sync daemon, fileproviderd, had been silently enrolled on my Desktop and Documents folders during macOS setup. I didn't realize my project folders were being synced. When fileproviderd detected what it interpreted as a conflict inside a .git directory, it renamed .git to "git 2."
That single rename makes a repository instantly invalid. HEAD points to nothing. Every git command fails. And because it happened silently, by the time I noticed, the damage had propagated through my entire development environment.
The timeline
-
April 12 Normal development day. Everything working. Commits, pushes, builds.
-
April 13 macOS update triggers
fileproviderdre-enrollment. iCloud silently begins syncing Desktop and Documents. -
April 14, 9:12 AM
git statusreturnsfatal. The.gitdirectory has been renamed to "git 2." -
April 14, 9:15 AM Investigation begins. No undo. No recovery path. No Time Machine snapshot with a clean state.
"I lost years of work in one afternoon. No warning. No recovery path. The sync daemon that was supposed to protect my files destroyed them."
Here is the short version of what happened. A macOS update quietly turned on iCloud sync for my project folders without asking. Two days later, everything stopped working.
April 12: Normal day
Everything worked perfectly. I was writing code, saving changes, and pushing updates to my team. No signs of any problem.
April 13: The silent change
A macOS update ran overnight. As part of that update, iCloud quietly started syncing my Desktop and Documents folders. I did not choose this. There was no notification. The setting was turned on automatically during the update process.
April 14, 9:12 AM: Everything breaks
I tried to open a project and got an error: "fatal: not a git repository." The hidden tracking folder inside my project had been renamed by iCloud. Instead of being called ".git" (which is what the system requires), it had been renamed to "git 2."
That tiny rename made the entire project unrecognizable. It was still there on my computer, but the tools could no longer find it.
April 14, 9:15 AM: No way back
I searched for an undo button, a recovery option, a Time Machine backup with the original state. None existed. The damage had already spread to every project in my synced folders. Years of work, silently broken by the very service that was supposed to keep it safe.
Why this matters to you
If your project folder is inside your Documents or Desktop folder on a Mac, it is probably being synced to iCloud right now. You may not have chosen this. macOS turns it on by default during setup and during certain updates. The same is true for OneDrive on Windows.
The failure presented as a silent .git directory rename with no process-level signal. No exit code, no log entry, no filesystem event that standard monitoring would catch. The root cause was iCloud's fileproviderd daemon, which was auto-enrolled on Desktop and Documents directories during a macOS system update.
Observable signal: T-2 days
April 12: All git operations nominal. git status, git push, git log return expected results. No anomalies in .git/ directory structure. This is the last known-good state. No automated system captured a snapshot at this point.
Observable signal: T-1 day
April 13: macOS update triggers fileproviderd re-enrollment. The daemon begins syncing ~/Desktop and ~/Documents to iCloud Drive. This enrollment produces no user-visible notification, no system log entry accessible to non-root processes, and no filesystem event distinguishable from normal file access. An agent monitoring FSEvents on ~/Documents would see file access patterns but no semantic signal indicating sync enrollment.
Observable signal: T+0 (failure)
April 14, 09:12: git status exits with code 128: fatal: not a git repository (or any of the parent directories): .git. Manual inspection reveals .git has been renamed to git 2. The rename was performed by fileproviderd's conflict resolution engine, which appends numeric suffixes when it detects concurrent modifications to the same directory across devices.
Failure pattern
The critical gap: between T-1 and T+0, there was a window where automated detection could have caught the enrollment and either alerted or created a protective snapshot. No tool in the current ecosystem monitors for cloud sync enrollment events on directories containing .git paths.
Recovery status at T+0: no Time Machine snapshot with pre-rename state, no git bundle backup, no off-machine copy of the .git object store. Total data loss for all repositories in the synced directory tree. The damage propagated to every project in ~/Documents/Projects/, not just one repository, but all of them.
It's not just iCloud
After the incident, I researched every major cloud sync provider. The pattern is the same everywhere.
Dropbox opens databases concurrently, bypassing app locks. Result: fatal: index file corrupt. Google Drive injects desktop.ini into .git directories on Windows and lacks support for hard links and symlinks. Cargo builds fail entirely. OneDrive dehydrates .git objects through Files-On-Demand, replacing actual data with cloud pointers. Microsoft's own community forums document the pattern.
Four providers. Four different failure modes. Same result: silently corrupted developer data.
| Provider | Users | Failure Mode | Result |
|---|---|---|---|
| iCloud | 850M | Renames .git on conflict | Repository invalid |
| Dropbox | 700M | Concurrent database access | Index corruption |
| Google Drive | 1B+ | Injects desktop.ini, no symlinks | Build failures |
| OneDrive | 400M | Dehydrates .git objects | Data replaced with pointers |
This is not just an iCloud problem. After my projects were destroyed, I researched every major cloud sync service. Every single one of them breaks projects in its own way.
iCloud: 850 million users
What it does: When iCloud sees a conflict between two devices, it renames your project's hidden tracking folder. Instead of ".git" it becomes "git 2" or ".git (conflicted copy)."
What that means for you: Your project instantly stops recognizing its own history. Every tool that reads from that folder fails. There is no undo.
Dropbox: 700 million users
What it does: Dropbox opens your project's internal database files at the same time your tools are using them. It ignores the "lock" files that are supposed to prevent this.
What that means for you: The internal index that tracks which files are staged for your next save gets scrambled. Your project reports that its index is corrupt.
Google Drive: over 1 billion users
What it does: Google Drive adds hidden system files inside your project's tracking folder on Windows. It also does not support certain file link types that projects depend on.
What that means for you: Builds fail. Tools that scan your project's internal structure find unexpected files and break. Projects that use linked folders stop working entirely.
OneDrive: 400 million users
What it does: OneDrive has a feature called "Files On-Demand" that replaces real files with lightweight cloud pointers to save disk space. It does this to your project's internal data files too.
What that means for you: Your project's stored data gets replaced with empty placeholders. When tools try to read the data, they get garbage instead of the actual content. Microsoft's own forums are full of reports about this.
The pattern
Four different services. Four different ways they break things. But the same root cause: they all treat your project's tracking system like a normal folder of independent files, when it is actually a carefully structured database that cannot be safely modified from the outside.
Cross-provider failure analysis. Four providers, four distinct corruption vectors, one shared root cause: violation of .git directory transactional integrity invariants.
iCloud: Rename corruption
Trigger: Multi-device access to same .git directory. fileproviderd detects conflict during sync reconciliation.
Artifact: .git renamed to git 2, .git (conflicted copy), or similar suffix. Original directory name destroyed.
Blast radius: Total repository invalidation. All git operations return exit code 128. Affects every repository in the synced directory tree. 850M users exposed.
Dropbox: Index corruption
Trigger: Concurrent file access. Dropbox's sync engine opens .git/index and pack files without honoring .lock file protocol. Race condition during git add, git commit, or git gc.
Artifact: Corrupted index file. git status returns fatal: index file corrupt. Conflict copies appear as .git/index (SomeoneElse's conflicted copy 2024-01-15).
Blast radius: Staging area destroyed. Partial recovery possible via git read-tree or index rebuild, but uncommitted staged changes are lost. 700M users exposed.
Google Drive: File injection + symlink failure
Trigger: Sync initialization on Windows. Google Drive Stream injects desktop.ini into .git/. No symlink or hardlink support on the FUSE mount.
Artifact: Unexpected files in .git/ directory. Worktree and submodule symlinks resolve to nothing. Build systems that glob .git/** encounter foreign entries.
Blast radius: Build failures, CI/CD pipeline breaks on workspace restore. Cargo, npm, and other package managers that traverse .git for metadata fail. 1B+ users exposed.
OneDrive: Object dehydration
Trigger: Files-On-Demand space reclamation. OneDrive replaces .git/objects/ contents with cloud-only reparse points after a period of non-access.
Artifact: Object files return zero-length or reparse-point data instead of zlib-compressed content. git fsck reports missing/corrupt objects. Pack index CRC validation fails.
Blast radius: Object store integrity compromised. Recovery requires re-fetching from remote, which only restores committed objects. Uncommitted work in the object store (pending blobs, unreachable trees) is permanently lost. 400M users exposed. Microsoft community forums document the pattern extensively.
Systemic implication
Four providers, four failure vectors, zero overlap in detection signatures. An agent framework that protects against iCloud rename is still vulnerable to Dropbox index corruption, OneDrive dehydration, and Google Drive injection. Comprehensive protection requires a detection layer that covers all four vectors simultaneously, or a backup strategy that bypasses the filesystem entirely.
2.75 billion users on broken platforms
iCloud serves 850 million users. Dropbox: 700 million. Google Drive: over a billion through Workspace. OneDrive: 400 million. That's 2.75 billion users on platforms that silently break git repos, SQLite databases, and symlinks.
Not all of them are developers. But any developer whose project folder sits inside a synced directory is affected. And most operating systems put you there by default.
This is not theoretical. Git's own official FAQ warns: "It is important not to use a cloud syncing service to sync any portion of a Git repository, since this can cause corruption." The providers know. They don't fix it because developers aren't their target customer.
These are not small services. Combined, they serve 2.75 billion users. None of them warn you about this problem.
You do not have to be a professional developer to be affected. If you have ever used an AI coding tool like Cursor, Windsurf, Replit, or Claude to build a project, and that project lives inside your Documents or Desktop folder, you are at risk.
Why this keeps happening
These cloud sync companies know about the problem. Git's own official documentation warns: "It is important not to use a cloud syncing service to sync any portion of a Git repository, since this can cause corruption." But the providers do not fix it because developers are not their primary customer. They built these services for documents, photos, and spreadsheets, not for code projects.
The worst part is that most operating systems put your files in a synced folder by default. On a Mac, your Desktop and Documents folders sync to iCloud automatically. On Windows, OneDrive does the same thing. You may not have chosen this, and you may not even know it is happening.
The bottom line
2.75 billion people use these services. Zero of those services warn you about the risk to your projects. And there are zero commercial tools designed to fix it. Until now.
Attack surface and exposure analysis. 2.75B user exposure across four providers. Zero provider-side mitigations. Zero tooling-side detection. This is an unmonitored failure class at planetary scale.
Exposure analysis
The affected population is not limited to developers who consciously choose to store repositories in cloud-synced directories. Both macOS and Windows default to syncing user home directories (Desktop, Documents) to their respective cloud providers during OS setup. Any agent framework, CI/CD runner, or automated workspace provisioner that creates repositories under these default paths inherits the exposure.
AI coding tools (Cursor, Windsurf, Claude Code, Copilot Workspace) frequently scaffold projects into ~/Documents or ~/Desktop based on user selection. Every project scaffolded into a synced directory is a ticking corruption event. The trigger is non-deterministic. It depends on cross-device access patterns, sync timing, and provider-specific conflict resolution heuristics.
Observable signal
Git's own official FAQ explicitly warns: "It is important not to use a cloud syncing service to sync any portion of a Git repository, since this can cause corruption." This is an acknowledged, documented failure mode that has been known for years.
The providers do not fix it because .git directories represent a negligible fraction of their total sync volume. Developers are not the revenue-generating customer segment for consumer cloud storage. This creates a permanent gap: the providers who cause the problem have no business incentive to solve it, and the developer tools that could detect it have no visibility into the sync layer.
What I looked for and didn't find
After recovering what I could, I went looking for the tool that should have prevented this. I evaluated over 40 tools across 9 categories. Every option was missing something.
| Tool Category | Examples | Local repos | Git-aware | Encrypted | Uncommitted |
|---|---|---|---|---|---|
| GitHub backup | Cloudback, GitProtect, Rewind | No | Partial | No | No |
| File backup | Restic, Duplicacy, BorgBackup | Yes | No | Yes | No |
| OS backup | Time Machine | Yes | No | No | No |
| Cloud backup | Backblaze | Skips .git | No | Yes | No |
| Custom scripts | DIY snapshot + cron | Yes | Yes | No | No |
The gap is clear: no commercial product combines local-first backup with git-aware atomic transport, client-side encryption, user-owned storage, and uncommitted work capture.
What a real solution needs
The table above shows the gap. No tool covers all four requirements. A real solution for this problem would need to:
- Read directly from git, not the filesystem. This is what makes backups immune to sync corruption.
- Capture uncommitted work: everything you haven't committed yet, not just committed history.
- Encrypt before transit. AES-256-GCM with keys that never leave the developer's machine.
- Store in user-owned buckets. Cloudflare R2, S3, or any compatible storage. No vendor lock-in.
- Verify every backup is restorable. Cryptographic receipts, not promises.
That's what DevSafe does. Not because I set out to check boxes, but because every requirement maps to a problem I personally hit.
$ devsafe scan
Scanning for git repositories in cloud sync zones...
~/Documents/Projects/api-server iCloud Drive
~/Documents/Projects/mobile-app iCloud Drive
~/Desktop/freelance/client-site iCloud Drive
~/Dropbox/code/side-project Dropbox
4 repositories at risk. 0 protected.
Run devsafe backup to protect them.Check whether your own repos are already at risk. Run devsafe scan to find out what's exposed.
After I recovered what I could, I went looking for the tool that should have prevented this. I searched through over 40 different backup and protection tools. None of them solved the actual problem.
GitHub backup tools (Cloudback, GitProtect, Rewind)
These tools back up what is already on GitHub. But the problem is not on GitHub. The problem is on your computer, in your local project folders. These tools never see your local files.
They also do not save your uncommitted work -- the changes you have made but not yet pushed. If you lose your local files, those changes are gone forever.
File backup tools (Restic, Duplicacy, BorgBackup)
These tools are great for backing up regular files. They can encrypt your data, which is good. But they treat your project like a folder of loose files.
That is exactly the same mistake the cloud sync services make. If they back up a project while the tracking folder is being modified, the backup itself can be corrupted. They also do not capture your uncommitted work.
OS backup (Time Machine)
Time Machine backs up your entire computer. But it does not understand project structure. It copies files one by one, which means it can capture a project in a half-broken state.
It also does not encrypt your backups by default, and it only works on macOS. If your Mac dies (like mine did), you need another Mac to restore from Time Machine.
Cloud backup (Backblaze)
Backblaze actually skips the hidden tracking folder entirely. It backs up your project files but not the thing that tracks all their history. So even a "successful" restore loses your entire project history.
What a real solution needs
After looking at every option, the requirements became clear. A real solution would need to do all of these things at once:
What the right tool must do
1. Read directly from your project's internal database, not the files that cloud sync can break.
2. Save your uncommitted work -- the changes you have not pushed yet.
3. Encrypt everything before it leaves your computer.
4. Store backups in your own cloud storage, not someone else's server.
5. Prove that every backup can actually be restored, not just promise it.
No tool I found does all five. That is why DevSafe exists. Check whether your own projects are at risk right now. Run the free scan to find out what is exposed.
Gap analysis across the existing tool landscape. Over 40 tools evaluated across 9 categories. No existing tool covers the agent workspace protection vector.
Gap: Remote-only backup tools
Tools: Cloudback, GitProtect, Rewind, BackHub
Capability: Back up remote repositories from GitHub/GitLab APIs. No local filesystem access.
Gap: Zero visibility into local workspace state. Cannot detect or protect against filesystem-level corruption. Cannot capture uncommitted work (index, working tree, stash, operation state). An agent that scaffolds a project locally and has not pushed to remote has zero protection from these tools.
Gap: Filesystem backup tools
Tools: Restic, Duplicacy, BorgBackup, Kopia
Capability: File-level deduplication and encryption. Local filesystem access. Strong encryption (AES-256).
Gap: Not git-aware. Back up .git/ as a bag of files, inheriting the same consistency violation that cloud sync causes. If .git/index is modified between scanning and backing up .git/objects/, the backup contains an inconsistent state. No uncommitted work capture. A restore from a filesystem backup of a corrupted .git directory restores the corruption.
Gap: OS-level and cloud backup
Tools: Time Machine (macOS), Backblaze, Carbonite
Capability: Whole-disk or whole-filesystem backup. Time Machine provides point-in-time snapshots. Backblaze provides continuous cloud backup.
Gap: Backblaze explicitly skips .git/ directories. Time Machine captures .git/ but without transactional consistency (it is a file-by-file copy, not an atomic snapshot of the object store). Neither captures uncommitted work as a semantic unit. Neither encrypts by default. Neither provides restorability verification.
Capability matrix summary
Five requirements for protecting an agent workspace from cloud sync corruption: (1) local filesystem access, (2) git-semantic transport (bundle, not file copy), (3) client-side encryption, (4) uncommitted state capture, (5) restorability verification. No tool in the current ecosystem scores higher than 2 out of 5. The maximum coverage is filesystem backup tools at 2/5 (local access + encryption). The gap at positions 2, 4, and 5 is absolute: zero tools address git-semantic transport, uncommitted capture, or verification.
For agent and pipeline builders: this means there is currently no tool you can integrate into a CI/CD pipeline or agent workspace provisioner that protects against this failure class. Custom scripts using git bundle cover requirement 2 but miss encryption, verification, and uncommitted state capture.
So I built it
DevSafe exists because I needed it first. Every feature solves a problem I personally hit. Encrypted backups that verify every byte. Git-aware transport that understands repository structure. Secret scanning that catches leaks before they happen.
"Not because I wanted to build a company. Because I never want to sit at a desk wondering if my work survived."
Read the full research: Every Major Cloud Sync Provider Corrupts Developer Data documents the systematic review with citations from public bug trackers, vendor documentation, and developer community threads.
So we built something that watches your projects for you. It works differently from every other backup tool because it was designed specifically for this problem.
It reads from git's internal database
Other backup tools copy files one by one from your project folder. That is the same approach cloud sync uses, and it is the reason backups can be corrupted too. DevSafe reads directly from git's internal database -- the structured, consistent record of your project -- and creates a single, self-contained snapshot. Cloud sync cannot break what it cannot see.
It encrypts everything before it leaves your machine
Your backup is encrypted on your computer before it goes anywhere. The encryption key never leaves your machine. Not even DevSafe can read your backups. They are stored in your own cloud storage account (like Cloudflare R2 or Amazon S3), not on our servers.
It saves your uncommitted work
Most backup tools only save changes you have already committed, the ones you have formally "saved" to your project history. But what about the work you are in the middle of? The file you changed ten minutes ago? DevSafe captures all of it: your staged changes, your working files, your stashed experiments, everything.
It proves every backup can be restored
Other tools promise your backups work. DevSafe proves it. Every backup comes with a cryptographic receipt that verifies every byte is intact and restorable. You do not have to trust us. You can verify it yourself.
DevSafe was not built to check boxes on a feature list. Every single feature maps to a real problem I personally hit when I lost my work. Read the full research behind this: Every Major Cloud Sync Provider Corrupts Developer Data.
DevSafe addresses the gap by reading from git's object database via git bundle, bypassing the filesystem corruption vector entirely. The architecture maps each capability directly to the failure modes documented above.
Architecture: Git-semantic transport
Failure mode addressed: All four provider corruption vectors (rename, index corruption, dehydration, injection).
Mechanism: git bundle create --all reads from the object database, not the filesystem. The bundle is a self-contained, self-consistent transport format that packages refs + objects into a single file. It is immune to filesystem-level corruption because it reads through git's internal APIs, not through file I/O on .git/ directory contents.
Validation: git bundle verify runs before encryption, catching any corruption at the transport layer before it propagates to the backup store.
Architecture: Client-side encryption
Failure mode addressed: Data exposure in transit and at rest.
Mechanism: AES-256-GCM with HKDF-SHA256 key derivation. Two-level key hierarchy: master key (never transmitted) derives per-repo keys, which derive per-bundle keys. Encryption happens before any network I/O. The storage provider (Cloudflare R2, S3, or any S3-compatible endpoint) receives only ciphertext. Zero-trust model: the backup is verifiable without trusting the storage provider.
Architecture: Five-namespace uncommitted capture
Failure mode addressed: Loss of uncommitted work during corruption events.
Mechanism: Atomic capture of five workspace namespaces: (1) staging index, (2) working tree modifications, (3) untracked files, (4) stash stack, (5) in-progress operation state (rebase, merge, cherry-pick). This is captured without creating a commit in the user's repository. Zero-commit capture. No HEAD advancement, no reflog pollution, no ref modification. The agent or pipeline's workspace state is preserved exactly as-is.
Integration surface for agent builders
DevSafe exposes a CLI (devsafe scan, devsafe backup, devsafe verify) that can be integrated into agent workspace provisioners, CI/CD pipelines, and local dev environment setup scripts. A pre-work scan detects repositories in cloud sync zones. A post-work backup creates an encrypted, verified snapshot. The full research is documented at Every Major Cloud Sync Provider Corrupts Developer Data.
Frequently asked questions
Why does iCloud rename .git folders?
iCloud Drive's sync engine resolves conflicts by appending version suffixes to files and folders it cannot merge. When two devices modify the same .git directory, iCloud renames it to something like '.git 2' or '.git (conflicted copy)'. Git requires the folder to be named exactly '.git' to function. Once renamed, git no longer recognizes the directory as a repository and returns 'fatal: not a git repository'. iCloud provides no warning and no built-in recovery path.
Does Dropbox or OneDrive also corrupt git repositories?
Yes. Every major cloud sync provider corrupts git repositories through different mechanisms. Dropbox creates conflict files inside .git and syncs files out of order. OneDrive's Files On-Demand feature dehydrates .git objects to placeholder files, making them unreadable. Google Drive locks files during sync, causing git operations to fail mid-write. The root cause is the same: cloud sync treats .git as a folder of independent files when it is actually a transactional database.
How do I safely back up a git repository that is in a cloud sync folder?
Move the repository out of the cloud sync folder (iCloud Drive, Dropbox, OneDrive, or Google Drive) and use a git-aware backup tool instead. A git-aware backup reads from git's object database using commands like git bundle, producing a self-consistent snapshot that is immune to sync conflicts. It then encrypts the bundle and uploads it to storage you control. This separates the backup path from the sync path, eliminating the corruption vector entirely.
Why does iCloud rename .git folders?
Every project that uses git has a hidden folder called ".git" that stores all of its history. When iCloud syncs your project between devices (like your Mac and your iPhone or iPad), it sometimes sees a conflict: two versions of the same folder that it cannot merge. Its solution is to rename one of them, adding a suffix like "2" or "conflicted copy."
The problem is that git requires this folder to be named exactly ".git" with no changes. Once iCloud renames it, your project can no longer find its own history. You get an error that says "fatal: not a git repository," which means the project no longer recognizes itself. There is no undo button and no warning before it happens.
Does Dropbox or OneDrive also corrupt git repositories?
Yes. Every major cloud sync service breaks projects, just in different ways. Dropbox opens your project's internal files at the same time your tools are using them, which scrambles the data. OneDrive has a space-saving feature that replaces real files with cloud-only pointers, which turns your project data into unreadable placeholders. Google Drive adds its own hidden files inside your project folder and does not support certain file link types that projects need.
The root cause is the same for all of them: they treat your project's tracking system like a regular folder of independent files, when it is actually a structured database that needs to be handled as one unit.
How do I safely back up a git repository that is in a cloud sync folder?
The safest option is to move your project out of the cloud sync folder (iCloud Drive, Dropbox, OneDrive, or Google Drive) and use a backup tool that understands how projects work internally. A good backup tool reads from your project's internal database instead of copying files one by one. This produces a single, consistent snapshot that cloud sync cannot break.
DevSafe does exactly this. It reads from git's internal database, encrypts the snapshot on your machine before it goes anywhere, and stores it in your own cloud storage. The backup path is completely separate from the sync path, so there is no way for the two to interfere with each other.
Why does iCloud rename .git folders?
iCloud's fileproviderd daemon implements conflict resolution by appending numeric suffixes to directories it cannot merge. The .git directory is treated as an opaque directory of independent files rather than a transactional object store. When two devices modify the same .git directory (which happens during any concurrent git operation), fileproviderd renames it to git 2 or .git (conflicted copy).
This is a silent, unrecoverable failure. Git resolves GIT_DIR by walking up the directory tree looking for exactly .git. Any rename produces exit code 128 with no other signal. There is no FSEvents notification distinguishable from normal file operations, no process-level alert, and no provider-side rollback mechanism. For agent frameworks: any workspace where .git integrity is assumed (clone, checkout, commit, push) is vulnerable if the workspace path falls within an iCloud-synced directory.
Does Dropbox or OneDrive also corrupt git repositories?
Yes. Each provider implements a distinct corruption vector. Dropbox bypasses .lock file protocol and opens .git/index concurrently, producing fatal: index file corrupt. OneDrive Files-On-Demand dehydrates .git/objects/ to reparse points, replacing zlib-compressed content with cloud-only placeholders that fail CRC validation. Google Drive injects desktop.ini into .git/ and lacks symlink/hardlink support, breaking worktrees and submodules.
The detection signatures are non-overlapping: iCloud produces a directory rename, Dropbox produces index corruption, OneDrive produces object store corruption, Google Drive produces foreign file injection. A comprehensive detection layer must cover all four vectors. For CI/CD and agent pipelines: any workspace cache, volume mount, or local clone path that intersects with a cloud sync directory inherits the full failure surface of whichever provider is active on that machine.
How do I safely back up a git repository that is in a cloud sync folder?
Separate the backup path from the sync path. The backup tool must read from git's object database (via git bundle), not from the filesystem. This bypasses all four corruption vectors because it reads through git's internal APIs rather than performing file I/O on .git/ directory contents.
DevSafe implements this as: git bundle create (atomic object store read) followed by git bundle verify (pre-encryption validation) followed by AES-256-GCM encryption (client-side, key never transmitted) followed by upload to user-owned S3-compatible storage. The bundle is a single, self-consistent file that contains refs + objects. It can be verified and restored independently of the original filesystem state. For agent workspace protection: integrate devsafe backup as a post-work step in your workspace lifecycle to create verified snapshots after each agent session.