When an Unattended Run Finds Its Working Folder Owned by Someone Else

A three-tier fallback that always lands somewhere writable

With the decision function in place, what remains is the landing strategy. The three tiers I use are these.

Tier three is the crux. A folder that has drifted in ownership belongs to someone else (nobody), so even rm -rf may be rejected. Persisting here never wins. Give up cleanly and switch to a location you can certainly write, such as $HOME/repos. For an unattended run, "run to completion in a writable place" is more correct than "cling to the ideal location and stall" — a judgment the mornings taught me more than once. I prefer this bias toward escaping over deleting.

# List candidates in priority order and settle on the first writable one.
# Returns the chosen working directory path on stdout.
resolve_workdir() {
  local site="$1"                      # e.g. antigravitylab.net
  local primary="/tmp/repos/${site}"   # the persistent folder we want to reuse
  local fallback="${HOME}/repos/${site}"
 
  # --- Tier 1: can we use the existing persistent folder as-is? ---
  if [ -d "$primary/.git" ] && is_writable_dir "$primary"; then
    if owner_is_me "$primary"; then
      echo "$primary"; return 0
    fi
    # Writable but not owned by me (rare, e.g. ACLs). Allow it, but log it.
    echo "WARN: $primary is writable but owner UID differs (ACL etc.)" >&2
    echo "$primary"; return 0
  fi
 
  # --- Tier 2: if broken, delete and rebuild ---
  if [ -e "$primary" ]; then
    echo "INFO: $primary not reusable. Attempting removal." >&2
    if rm -rf "$primary" 2>/dev/null && mkdir -p "$primary" 2>/dev/null && is_writable_dir "$primary"; then
      echo "$primary"; return 0
    fi
    echo "WARN: cannot delete/recreate $primary (likely owned by another user)" >&2
  else
    # Only absent so far: test whether we can create it.
    if mkdir -p "$primary" 2>/dev/null && is_writable_dir "$primary"; then
      echo "$primary"; return 0
    fi
  fi
 
  # --- Tier 3: escape to a per-user location ---
  mkdir -p "$fallback" 2>/dev/null
  if is_writable_dir "$fallback"; then
    echo "INFO: using fallback $fallback" >&2
    echo "$fallback"; return 0
  fi
 
  echo "FATAL: could not secure a writable working directory" >&2
  return 1
}

The caller does not hardcode the path; it uses the function's return value.

SITE="antigravitylab.net"
WORK="$(resolve_workdir "$SITE")" || { echo "Failed to secure a working folder. Aborting run."; exit 1; }
echo "Working directory: $WORK"
 
# From here, $WORK is guaranteed writable, so clone / pull can branch safely.
if [ -d "$WORK/.git" ]; then
  git config --global --add safe.directory "$WORK"
  cd "$WORK"
  git remote set-url origin "https://${TOKEN}@github.com/${SITE%.*}/${SITE}.git"
  git reset --hard HEAD; git clean -fd
  git pull --rebase origin main
else
  git clone --depth 1 --branch main "https://${TOKEN}@github.com/${SITE%.*}/${SITE}.git" "$WORK"
  cd "$WORK"
fi
git config user.email "you@example.com"
git config user.name  "Your Name"

The second wall: Git refuses even when you can write

There is a reason I slip in git config --global --add safe.directory "$WORK". When you reuse a folder whose owner just changed, Git can refuse every operation with detected dubious ownership. The write itself goes through, yet Git's ownership check stops you — a wall on a different layer. If you are dealing with ownership drift, this one line is almost a required companion. I learned that the hard way when a folder became writable again and Git's check tripped me a second time, because I had forgotten to add this line.

Order matters too. Register safe.directory before cd or git reset. In a dubious-ownership state almost every git subcommand is rejected immediately, so registering it late means the git config itself may pass while the earlier reset has already failed. Treat the writability check and the ownership registration as one continuous, two-layered wall.

What six weeks of unattended runs taught me

Here is the record from running the same four-site schedule before and after adding this design. The sample is six weeks and 47 runs after the preflight went in.

The numbers look modest, but the one thing that mattered to me was that morning patching went to zero. In about 80% of the events — four of five — the run finished via the Tier 3 escape; even when the /tmp persistent folder became someone else's property, that day's article generation did not stop. Tier 2 (delete and rebuild) was enough only once. In other words, most ownership drift is discovered in an "I can no longer delete this" state, and betting on the escape holds up better in practice than betting on removal — a feel that matched the data.

The preflight cost at most about 120 ms per run: creating and removing a probe file, one stat, and a mkdir -p attempt. As a preamble to a run that takes tens of minutes, it is within the noise. Skimping here and running on the existence check instead — then tripping midway through a pull and leaving a half-written state — costs far more to clean up in total.

Idempotency, so the same morning never returns

One last caution when you fold this function into an unattended run: it matters that resolve_workdir settles on the same conclusion no matter how many times it is called. So that a run retried midway does not scatter work across yet another folder, I keep to three rules:

1. Always remove the probe file; leave no litter behind on each check
2. Never make a Tier 2 removal failure fatal; fall quietly through to the next tier
3. Pin the fallback to the same path every time; do not let retries multiply it

When working folders multiply under unattended operation, the next morning waiting for you is a different one: disk exhaustion. A design that does not multiply folders is, in the same breath, a design for stable operation.

Reusing a working folder is a plain trick for getting both speed and stability out of an unattended schedule. Just adding the small step of asking "can I write here right now" instead of "does it exist" removes one red log from the morning. For the surrounding footing of scheduled runs, reading streaming unattended run logs into SQLite to count failures across runs and designing a pipeline that runs the Antigravity CLI on a schedule alongside this lets you tidy everything from the footing to the tallying in one line. From the different angle of write atomicity, guarding an unattended agent against half-written files covers a nearby problem.

Start by replacing a single [ -d "$WORK/.git" ] in your pipeline with is_writable_dir "$WORK". I am still finding my footing with unattended operation myself, but when the mornings stay quietly green for a stretch, I let out a small breath of relief. Thank you for reading.