Overnight Claude mesh cron was armed against an active Codex worktree and would have stomped 14 modified files on first fire

Overnight Claude mesh cron was armed against an active Codex worktree and would have stomped 14 modified files on first fire

Summary

On 2026-04-15T03:10Z, the overnight Claude mesh cron was being armed with cd /Users/chadbarlow/gh/camber as the working directory. A pre-arm reconnaissance step revealed that the camber repo at that path was CODEX-DESKTOP-MacBook-Air-CAMBER-01's active worktree, with 14 modified uncommitted files including the exact RedlineMac Swift files the mesh had been planning to touch. The first cron fire would have either stomped Codex-01's in-progress v3.5.4 work or produced merge-conflict cascades. The collision was caught manually, not by tooling.

Evidence

What the cron was about to do

• CronCreate prompt was being drafted to fire every 22 minutes for ~4 hours, running git status, git diff, and (conditionally) git commit operations against /Users/chadbarlow/gh/camber.
• The mesh plan included matview migration work and Swift decoder reads — both of which Codex-01 was actively editing in the same worktree.

What recon found

• 14 modified uncommitted files in /Users/chadbarlow/gh/camber.
• Active edits to supabase/functions/redline-thread/index.ts (v3.5.4 in progress).
• Active edits to RedlineMac Swift files in ios/CamberRedline/.
• Branch codex/cmb-0007-timeclock-ios checked out, ahead of main.
• HEAD = 1c7fe50da91073e872888391451cf0e42bba3ff4 (Codex-01's pending v3.5.4 commit).

What the failure mode would have been

Three concurrent failure paths, any of which would have lost work: 1. Implicit checkout/branch switch on cron fire would have aborted with "your local changes would be overwritten" — best case. Cron would log an error and skip, but Codex-01's session would see unexpected git lock contention. 2. A stale-cache rebuild triggered by the cron's working directory would have invalidated Codex-01's in-progress Xcode incremental-build state, costing 4–8 minutes of re-build per fire across the overnight window. 3. A git commit operation from the mesh would have committed Codex-01's modified files under the mesh's identity, attributing v3.5.4 work to the wrong author and producing a non-reproducible commit graph.

How the collision was avoided

Manual reconnaissance step before arming the cron:

cd /Users/chadbarlow/gh/camber
git status
git branch --show-current
git rev-parse HEAD

Recon revealed the dirty state. Fix was to create an isolated worktree:

git worktree add -b claude/redline-overnight-20260415 \
  /Users/chadbarlow/gh/camber-redline-overnight \
  1c7fe50d

The cron was then re-armed with cd /Users/chadbarlow/gh/camber-redline-overnight instead. Codex-01's worktree at the original path remained untouched.

Impact

• Zero actual data loss because the recon step caught it.
• Estimated avoided loss: 4-hour overnight window of mesh work + Codex-01's v3.5.4 commit attribution + 4–8 min × N rebuild cost.
• The rule is M1 (one near-miss, no second corroboration) but the failure mode is well-characterized.

Implications

• Pattern: every CronCreate or recurring schedule that contains a cd <path> followed by git operations is a latent collision vector if the target path is a shared worktree.
• Same class as ORA-2026-0003 / ORA-2026-0004: a default assumption (working directory is "clean enough") hid the actual state until the rule fired. The fix is to make the state check explicit and pre-arm.
• Fix: pre-arm git state verification doctrine. Codified in ORA-2026-0010.

References

• Worktree path: /Users/chadbarlow/gh/camber-redline-overnight (created during recon).
• Branch anchor: claude/redline-overnight-20260415 = 1c7fe50da91073e872888391451cf0e42bba3ff4.
• Backlog filing: /Users/chadbarlow/Desktop/ora/ORA_WORK_BACKLOG.md ORA-0004 (filed 03:10Z).