Repository navigation
Stale-checkout pre-flight block should self-heal by pulling main, not hard-fail the whole run #804
Description
Current behaviour: when a run starts and the local checkout is behind origin/main, the pre-flight check refuses to start the coding_loop_start run at all — it hard-fails with a message telling the human to manually run git pull --ff-only on the machine themselves. If there's an uncommitted file blocking the fast-forward, the run just fails again with the same message, with no path for the agent itself to clean it up, because the run never even starts.
This has caused a full block today across at least two instances (ProAgentStore/platform coder and Heartfull App Coder) — repeatedly failing with the same stale-checkout message, requiring a human to intervene manually on the runner machine. If the runner machine is also unreachable (as happened with the Heartfull runner, RLs-MacBook-Air, going offline), there is currently no way to unblock it at all short of physical access.
Requested fix: separate 'may this run touch a ticket / do write work' from 'may this run bring the checkout up to date'. Specifically:
- Before a coding_loop_start run begins doing ticket work, it should automatically attempt to sync the checkout to origin/main itself (fetch + fast-forward pull), including safely handling minor obstructions like stray untracked files (e.g. git clean on known-safe untracked paths, or stashing) — without needing a human to SSH in.
- The hard lock should apply only to starting substantive ticket/build work on a stale base, not to all agent activity. A narrower sync-only capability should always be available and should not be gated behind the same block it's meant to resolve.
- If the checkout truly cannot be safely reconciled (e.g. real uncommitted work, unresolvable conflict), only then should it hard-fail and surface a clear, specific reason — not the same generic message regardless of cause.
Goal: stale checkouts should self-heal automatically in the common case, and only escalate to a human when there's a genuine conflict that requires judgment.
Activity
proagentstore commentedon Sep 12, 2026
Current live blockage, for context on urgency and scope:
ProAgentStore/platform coder (this repo, instance a185b1db): checkout was 20 commits behind origin/main (local 5b671b2 vs origin/main 7fcfc6f). This one recovered once the runner responded again and a coding_loop_start run was retried — no uncommitted-file obstruction here, so it was able to proceed.
Heartfull App Coder (Heartfull-online/platform, instance f8ddc272): checkout was 18 commits behind origin/main (local 2a3ec3cd vs origin/main 65014f40). Two coding_loop_start retries both failed with the same message: 'This run was stopped before it started because the base it would build on could not be confirmed (Sync-check fix (#785) is not reliably working: runner /coding/sync 404s recur, checkouts still fall behind silently #801)... A fast-forward was not attempted: it was not fast-forwarded because the working tree has 1 uncommitted file.' The offending file is an untracked
.claude/folder — confirmed via repo_git status to be tooling cruft, not real work, and safe to remove. But because the run never starts, the agent never gets a chance to clean it up itself.Attempting to route around the block entirely via a direct coding_session_message (bypassing coding_loop_start) failed differently: 'Error waking heartfull/platform: Runner node is not connected: RLs-MacBook-Air' — the physical runner machine itself was unreachable, so even a manual/direct git clean + pull instruction couldn't be delivered.
So today's block had two independent failure layers stacking: (a) the hard pre-flight lock refusing to start any run on a stale checkout with an uncommitted file, with no self-heal path, and (b) the runner machine being intermittently unreachable, which meant even manual intervention wasn't guaranteed to land. Fixing (a) as described in this issue would have avoided needing any manual step for the Heartfull case, since the untracked .claude/ file was trivially safe to clean automatically — the run simply never got the chance.
fix(test): name the goal's shape in the driver test, which turned the…
feat(coding): a run cut off with its work still uncommitted briefs it…
test(#915): the Pilot's invariants are asserted by RUNNING the workfl…