A Synced Folder Corrupted My AI Coding Sessions

This one took me months to figure out, and for most of that I did not even realize it was one problem. It came and went. I would go weeks with everything running clean, sure that whatever it was had sorted itself out, and then in the middle of some long autonomous session it would just happen again, out of nowhere.

What it looked like

Access denied. EPERM, over and over, on files the agent had written a second earlier. I would paste the error into Google, read the same handful of threads everyone else ends up on, paste it back to the AI, and the two of us would try to bring the corrupted session back to life. Sometimes it would seem fine again for a bit, and then it would come back.

What really threw me is that I usually have ten or more sessions going at once, and the corruption did not stay put. One session would start throwing these errors, and then another one would catch it, and then another, and I could not tell which one had started it. So I was not debugging a single problem. I was watching it spread from session to session and trying to figure out which session it began in.

And the whole time I was treating it as a tooling problem. I would try to rescue the corrupted session, and when that failed I would restart the machine and work around whatever came next. It genuinely never occurred to me to look at where the files were sitting. And because it only hit after a long run, and only sometimes, a clean week or two would go by and I would figure it was gone. That is the part that got me. Every time it stopped for a while, the next failure was harder to make sense of, not easier.

What it actually was

When I finally found it, it was almost embarrassing. My repos were sitting in ~/Documents/GitHub, and on a Mac that folder syncs to iCloud automatically. So iCloud and the coding agent were both writing to the same files at the same time, and they kept getting in each other's way. That was the corruption. I moved everything to ~/code/GitHub, which nothing syncs, and it stopped. Months of this, and the fix was a different folder.

Why I keep thinking about it

The folder was the easy part. What it left behind was not. Somewhere in those months I stopped trusting what the factory was producing. If a file could get quietly corrupted and read back wrong without anything obviously breaking, then I could not tell how much of the finished work was actually finished, and how much only looked that way.

That question stuck around long after the errors stopped. It is why the next thing I put real time into was not more agents or faster runs. It was verification. I could not keep taking the output on faith, so I started making the factory prove it instead.

That part is a longer story, and I will tell it on its own.