tests/test_shape_doctor.py, tests/conftest.py and setup-project.py: a clone of a just-pushed --local-remote-dir bare repository is git's local clone, which links or copies each loose object file while git's background maintenance can pack and delete them, so on the macOS runner it dies failed to copy file to ... No such file or directory, every doctor test errors at setup, and setup.sh refuses after creating all three repositories #440

Lane: openreposhape-3 (openRepoShape-3)

What happens. Three CI attempts of the tests workflow failed this way, all on the macOS runner (macos-26-arm64, git 2.55.0). The ubuntu and windows runners report git 2.55.0 too and have no occurrence. <tmp> is pytest's temporary root on the runner.

The first two passed on gh run rerun --failed. Every failed tests check run since 2026-09-12 was searched, in every attempt (26 check runs, 400 workflow runs), and only these three carry the error.

Why it fails. Each failing command clones a plain path, for example git -c protocol.file.allow=always clone -q --recurse-submodules <remotes>/Atlas.git <clones>/Atlas. That is git's local clone, which walks the source's objects/ directory and handles each file in turn:

1. It link()s the file.
2. When the link fails and --local was not given, it falls back to copying.
3. A failed copy dies with failed to copy file to '<dest>' and the errno.

ENOENT here is a loose object the walk had just listed, gone by the time it was linked and copied. In a bare remote that nothing else writes to, only a repack's prune of packed loose objects removes one. The scaffold has just pushed into that remote, and git's automatic maintenance can run detached after a push.

The same runner shows that maintenance at work. PR #345's first macOS attempt (run 38249646229, job 114812791114) failed five tests/test_family_dry_run.py tests on a stray objects/maintenance.lock, and 3ae0109 turned maintenance off for that module. The actor in the clone failure is inferred from that evidence, not observed: git 2.55 is not available here, and local git is 2.43.

Measured locally (git 2.43), on a bare repository holding 7 loose objects:

git clone <path>               loose=7 packs=0   object link count 2   (hard links: the same per-file walk)
git clone --no-hardlinks <path> loose=7 packs=0  object link count 1   (copies: the same per-file walk)
git clone --no-local <path>    loose=0 packs=1                         (upload-pack sends one pack)
git clone file://<path>        loose=0 packs=1

And the module-level switch-off does not reach the remote. A local git push with receive.unpackLimit=1 in GIT_CONFIG_COUNT/_KEY_0/_VALUE_0, or with -c, still left all the objects loose. The same value in the remote's own config made a pack. So NO_MAINTENANCE in tests/test_family_dry_run.py would not stop maintenance that a push starts in a --local-remote-dir remote.

Where. On 45e01f4:

• tests/test_shape_doctor.py:scaffolded_here (:134-146): git clone -q --recurse-submodules <remotes>/Atlas.git, right after scaffold().
• tests/conftest.py:scaffolded (:295-316): the same clone, right after the scaffold. No occurrence is recorded there yet.
• setup-project.py (:1704-1710): the clone setup.sh runs. Under --local-remote-dir, urls["assembly"] is a plain path.
• --recurse-submodules clones each leg remote by path too. No occurrence is recorded there.

Why it matters. One lost race fails the whole macOS job: every doctor test errors at setup. The three-OS gate then holds the PR until somebody reruns the failed jobs, about 20 minutes each time; on 2026-10-12 it happened twice in about 90 minutes. Under setup.sh --local-remote-dir, the refusal comes after all three repositories exist.

Direction: read the just-pushed remote through the transport, not through its files. That means --no-local (or a file:// URL) on the root clone, in both session fixtures and in setup-project.py's --local-remote-dir clone. Upload-pack reads objects through git's object store, which survives a concurrent repack. What does not fix it:

• --no-hardlinks, which is the same per-file walk;
• a retry, which hides the race;
• the environment switch-off, which does not reach the remote.

The fix should say whether it also covers the leg remotes that --recurse-submodules clones by path.

What must be kept:

• protocol.file.allow=always, for the submodules;
• one scaffold per session;
• the clone from GitHub, which this does not touch.

Source. Lane 3's coordinator note on PR #344's first macOS attempt (2026-10-12), rerun green with gh run rerun --failed. The other two occurrences were found by the search above. Related: PR #345 and 3ae0109 (the same background maintenance, seen as maintenance.lock in tests/test_family_dry_run.py).