Observed on main at f66be0f.
Symptom
Spawning a worker for a genuinely local-only project - one registered with no remote at all - fails before the worker starts, with:
error: could not fetch origin for pooled worktree '<path>'; refusing to launch from a potentially stale base
The task cannot be dispatched at all.
Cause
bin/fm-spawn.sh calls freshen_spawn_worktree_base "$WT" || exit 1 for every fresh ship or scout worker.
That function's first action is:
if ! git -C "$worktree" fetch --quiet origin; then
echo "error: could not fetch origin for pooled worktree '$worktree'; refusing to launch from a potentially stale base" >&2
return 1
fi
A project with no origin configured has no remote to fetch, so this fails and the spawn exits 1.
Why this looks like an oversight rather than intent
The refusal is clearly deliberate and correct for its stated purpose, which the function header describes as avoiding a PR built on stale history.
But that reasoning does not apply to a project with no remote:
- A configured but unreachable origin genuinely is a stale-base risk and should keep refusing.
- A project with no origin at all has nothing to freshen against and no PR to build, so there is nothing to be stale relative to.
AGENTS.md documents local-only as a supported delivery mode, and the project registry format supports registering a project with no remote, so the two appear to be in tension.
Distinguishing the two cases before the fetch would be one way to resolve it, but we are not opening a PR for this - you will know better whether the local-only path should be handled here or earlier.
Observed on
mainatf66be0f.Symptom
Spawning a worker for a genuinely local-only project - one registered with no remote at all - fails before the worker starts, with:
The task cannot be dispatched at all.
Cause
bin/fm-spawn.shcallsfreshen_spawn_worktree_base "$WT" || exit 1for every fresh ship or scout worker.That function's first action is:
A project with no
originconfigured has no remote to fetch, so this fails and the spawn exits 1.Why this looks like an oversight rather than intent
The refusal is clearly deliberate and correct for its stated purpose, which the function header describes as avoiding a PR built on stale history.
But that reasoning does not apply to a project with no remote:
AGENTS.mddocumentslocal-onlyas a supported delivery mode, and the project registry format supports registering a project with no remote, so the two appear to be in tension.Distinguishing the two cases before the fetch would be one way to resolve it, but we are not opening a PR for this - you will know better whether the local-only path should be handled here or earlier.