Why Antigravity Agents Build Your Xcode Project Fine One Day and Break It the Next on a Synced Folder

.gitignore Will Not Save You (Git and Sync Are Different Layers)

Here is where many people get caught: "it's in .gitignore, so it's fine." .gitignore only controls what Git commits. The Dropbox or iCloud sync daemon never reads .gitignore at all. A directory Git ignores is still dutifully uploaded by the daemon.

So the fix has to happen on a different layer — telling the sync daemon itself "do not sync this folder." On macOS, Dropbox offers a per-item extended attribute for exactly this.

Exclude Volatile Directories From Sync — Mark Them With xattr

Dropbox for macOS excludes any file or directory whose extended attribute com.dropbox.ignored is set to 1. Run this script once at the project root to exclude the volatile directories in one pass.

#!/bin/bash
# mark-volatile-ignored.sh — exclude Xcode volatile dirs from Dropbox sync
set -euo pipefail
 
# run from the project root
TARGETS=(
  "Pods"
  "build"
  "DerivedData"
  ".swiftpm"
)
 
# also include user-specific metadata inside *.xcodeproj / *.xcworkspace
while IFS= read -r -d '' p; do
  TARGETS+=("$p")
done < <(find . -type d \( -name "xcuserdata" -o -name "*.xcuserdatad" \) -print0)
 
for t in "${TARGETS[@]}"; do
  if [ -e "$t" ]; then
    xattr -w com.dropbox.ignored 1 "$t"
    echo "ignored: $t"
  fi
done

Confirm it took effect with the command below. A return value of 1 means the directory is out of sync scope.

xattr -p com.dropbox.ignored Pods
# => 1

If you use iCloud Drive the mechanism differs: append .nosync to the folder name, or move build output outside the synced area entirely (for example ~/Library/Developer/Xcode/DerivedData). I keep build output outside the synced folder from the start, but for things that must sit at the project root — like CocoaPods' Pods/ — I rely on the xattr exclusion above.

A Clean Build Erases the Mark — Plug It With a Run Script

There is one more trap. The xattr mark lives on the directory, so a clean build that recreates the directory wipes the mark along with it. Set it once and relax, and conflicted copies quietly return after the next clean build.

The fix is to re-apply the mark on every build. Add a Run Script phase to your target that re-applies the exclusion early in the build.

# Build Phases > Run Script (uncheck "Based on dependency analysis")
# re-stamp the ignored attribute onto freshly created directories
for d in "${PODS_ROOT:-$SRCROOT/Pods}" "$SRCROOT/.swiftpm" "$SRCROOT/build"; do
  [ -e "$d" ] && /usr/bin/xattr -w com.dropbox.ignored 1 "$d" 2>/dev/null || true
done

If you use CocoaPods, put the same logic in the post_install hook of your Podfile so the mark is applied right after pod install.

# Podfile
post_install do |installer|
  system("xattr -w com.dropbox.ignored 1 \"#{installer.sandbox.root}\"")
end

With this in place, Pods/ is regenerated already outside sync scope every time you reinstall dependencies, so a lockfile turning into a conflicted copy mid-pod install becomes far less likely.

Inspect for Conflicted Copies Before Running the Agent

Even with exclusion in place, an old conflicted copy can linger in a corner of the folder. If the agent grabs it, you hit the same failure again. So before handing a task to the Antigravity agent, add a preflight that confirms there are no conflicted copies. The very first step of a scheduled run is the right place for it.

#!/bin/bash
# preflight-no-conflicts.sh — refuse to run the agent if conflicted copies remain
set -euo pipefail
 
# catch Dropbox conflicted copies and iCloud-style duplicates
HITS=$(find . \
  \( -iname "*conflicted copy*" \
  -o -iname "* 2.lock" \
  -o -iname "*.lock.sb-*" \) \
  -not -path "*/.git/*" 2>/dev/null)
 
if [ -n "$HITS" ]; then
  echo "🛑 Conflicted copies detected. Aborting the agent:"
  echo "$HITS"
  exit 1
fi
 
echo "✅ Clean — agent run permitted"

The key is to stop with exit 1. For unattended runs the default has to be "stop when in doubt," not "proceed when in doubt" — otherwise a corrupted state rides all the way through to a commit and a push. In automation like this I make a point of never continuing past a situation I am unsure about; I fail early on purpose. Surfacing the failure sooner makes the cleanup far lighter.

What to Keep in Sync, What to Exclude

Finally, the dividing line. When unsure, judge by two questions: "is it worth sharing with another Mac?" and "can it be regenerated if it disappears?"

Putting *.lock in the "keep" column is the awkward call. It pins dependency versions, so you want to share it — yet it is also the file most likely to conflict during a build. I settled on excluding Pods/ entirely and keeping Podfile.lock at the repository root (outside the volatile directories), shared via Git. Physically separating the responsibilities of the sync daemon and the build is the least breakable arrangement I have found.

If You Want to Try It on a Single App First

Fixing several apps at once makes it impossible to tell which change helped. Start with one project: mark Pods/ and .swiftpm with xattr -w com.dropbox.ignored 1, confirm xattr -p returns 1, then watch a few nights of agent runs. The failure rate should drop noticeably. From there, add the Run Script and the preflight to build a foundation that holds up even when it runs unattended.

Cloud sync is a strong ally for an indie developer, but it needs its turf kept separate from a build, where state changes by the second. Draw the boundary between what you trust to sync and what you trust to the build once, properly, and you can let an agent take the night shift with some peace of mind.