7 scripts resolve the repo root with an unguarded 'git rev-parse --show-toplevel' — git refuses the container's bind-mounted tree, so a path question gets no answer

Generalised from the root cause tab 2 captured for #3581's shard 3/3 failure.

The mechanism

The container bind-mounts the tree as uid 1000 and runs as root, so git refuses the repository outright:

fatal: detected dubious ownership in repository at '/workspace'
To add an exception for this directory, call:
	git config --global --add safe.directory /workspace

It refuses every question — including one that was only ever about a path. git rev-parse --show-toplevel needs no repository semantics at all; it is being asked where the tree is, and git declines to say because of who owns it.

That failed falsify_ggml_003_extractor_case_table_passes in monorepo_invariants, cost a 14m12s shard, and — through nextest fail-fast — prevented the 15 later commands in that shard from running at all, so the new 350-aprender-quant-ggml-traits-fixture.cmd fragment was never exercised on that head. One unguarded call took out a shard and silently skipped unrelated coverage.

Scope

git rev-parse --show-toplevel appears in 22 scripts. Most guard it (2>/dev/null || pwd). Seven do not, and these are the exposure:

scripts/check_exclude_anchored.sh:25            repo_root="${1:-$(git rev-parse --show-toplevel)}"
scripts/mutate_spec_conformance.sh:17           REPO_ROOT=$(git rev-parse --show-toplevel)
scripts/check_bashrs_gate.sh:210                gate "$(git rev-parse --show-toplevel)"
scripts/dogfood.sh:1508                         DF_SCRIPT="$(git rev-parse --show-toplevel)/scripts/dogfood-use.sh"
scripts/check_pathonly_devdeps_unused_in_src.sh:36   REPO="$(git -C "$(dirname "$0")" rev-parse --show-toplevel)"
scripts/ship-two-001/ex-05-verify-manifest.sh:29     REPO_ROOT="$(git rev-parse --show-toplevel)"
scripts/pr_review_quorum_arm.sh:199             REPO=$(git rev-parse --show-toplevel 2>/dev/null) \

check_bashrs_gate.sh and dogfood.sh are the two that matter most — both run in the container job set, and both would resolve to an empty path and then act on it.

The fix, which is the one tab 2 already applied

Derive the root from $0, and ask git only the questions that are genuinely about a repository. In the fixed scripts, git is asked exactly one thing — whether the llama.cpp checkout sits at the pinned sha — which is a repository question. Where the tree is is not.

Positive control, and the technique is reusable

Tab 2 proved the fix under the container's exact condition without a container: shadow git with a stub that prints the dubious-ownership message and exits 128, then run. Self-test → 7 cases, 0 failures; extractor → gets past root resolution and pin reading, and fails where it should.

That stub belongs in the repo as shared test scaffolding. Every one of the seven sites can be red-turned against it in seconds, and no runner time is needed to reproduce a container-only failure.

Seven sites resolve the root without git, or guard it with an explicit failure that names the condition.
A committed git-refuses-the-tree stub, and each fixed site red-turns against it.
A guard refusing a new unguarded --show-toplevel; falsifier: plant one and require RED.

Refs #3080, #3581

Ruling (operator): `|| pwd` is the wrong guard — the "guarded" sites are the deeper defect

git rev-parse --show-toplevel || pwd turns a refusal into a silent substitution — the script proceeds on whatever directory it happens to be in. That is the fail-open shape with a tidier face.

The seven unguarded sites are the visible finding; the fallbacks are the real one. Split measured:

form	count	what happens when git refuses
unguarded	7	empty path, then acts on it
`\|\| pwd`	5	silently proceeds on the current directory — wrong root, no signal
`\|\| exit 1` / `\|\| var=""`	9	refuses or empties; the `=""` cases then behave like the unguarded set
documented-only (comments)	1	—

So 12 of 22 either substitute a wrong root or carry on with an empty one, and only predict_merge.sh:64 (|| exit 1) fails closed.

What lands

One shared repo_root() in the sourced lib, and it does two things:

Sets safe.directory for the mounted tree in the container job set — in the runner image, via forjar, not per script. That is the actual fix: git refusing a bind-mounted tree is an environment defect, and 22 scripts working around it is 22 copies of a workaround.
Refuses by name when git still refuses — Unknown{NoRepoRoot}, exit 2. Never pwd, never empty. Doctrine 4: a question that could not be answered is Unknown, not a substituted guess.

The sourced lib must stay option-neutral — no set -euo pipefail in a file others source; fail by return status (. scripts/lib.sh || exit 1). That rule exists here because apr_bin.sh once leaked -e into qwen-story.sh and killed a nightly six lines in.

Positive control, corrected

All 22 sites RED against the stub, not seven. The || pwd sites are the ones most likely to pass a naive control while still being wrong — they produce a plausible path, so a test that only asserts "a root was returned" cannot see the defect. The control must assert the root is correct, or that the refusal is named.

safe.directory set for the mounted tree in the runner image, via forjar — not per script.
repo_root() in the sourced lib, option-neutral, refusing Unknown{NoRepoRoot} exit 2.
All 22 call sites converted; 0 remaining || pwd.
Committed git-refuses-the-tree stub; all 22 red-turn against it before conversion, all green after.
Guard refusing a new --show-toplevel outside the lib; falsifier: plant one, require RED.

The acceptance predicate could be satisfied wrongly — fixing that before anyone starts

From the lane that found the original failure, and it is the most important line in this ticket:

|| pwd is not a fix, it is a quieter bug. The fifteen guards that carry it do not fail; they silently locate the root at the caller's cwd and then read or write the wrong tree.

That is the transcript-gate-from-a-linked-worktree shape — a vacuous PASS, not a red. It is strictly worse than the seven unguarded sites, which at least break loudly.

So the predicate is derives the root from $0 — NOT guards the git call. If the ticket is read the second way, the correct-looking fix is to add || pwd to the seven, every site goes green, the guard suite reports clean, and the failure has been made invisible rather than removed. A ticket that can be closed green by making its own defect unobservable is the thing this repository keeps re-finding; this one would have been a textbook case.

The stub, verbatim, so it is not lost in a session

# tests/fixtures/git-refuses/git   (chmod +x, prepended to PATH)
#!/bin/sh
# The CI container's git, exactly: uid 1000 owns the bind-mounted tree, the
# container runs as root, and git declines EVERY question about it — including
# one that was only ever about a path.
echo "fatal: detected dubious ownership in repository at '/workspace'" >&2
exit 128

PATH="$(pwd)/tests/fixtures/git-refuses:$PATH" bash scripts/<guard>.sh

Red-turns a site in about a second, needs no runner. That is the whole value: a container-only failure reproduced without a container.

Two notes from using it in anger

The case table must assert the refusal, not an exit code. Under the stub, the two already-fixed scripts exit 3 and 0 — both correct, for different reasons. A table keyed on a specific exit status would mark one of them failing while it behaves exactly as intended.
All 22 sites, not seven — and for the || pwd five the assertion has to be that the resolved root is correct, since they return a plausible path and would satisfy any weaker check.

Acceptance, restated

safe.directory for the mounted tree fixed in the runner image via forjar — the environment defect, fixed once, not worked around 22 times.
Shared repo_root() in the sourced lib, option-neutral, deriving from $0, refusing Unknown{NoRepoRoot} exit 2 when git is genuinely needed and refuses.
Zero remaining || pwd on a root resolution. The count is the predicate.
Stub committed at tests/fixtures/git-refuses/git; all 22 sites red-turn against it before conversion; the table asserts the refusal, not a status.
Guard refusing a new --show-toplevel outside the lib; falsifier: plant one, require RED.

Owner: the correctness lane has offered to take it after M1's Phases 3–4 — the $0 derivation is the same two lines in all seven, and they have the stub warm. Unassigned until then; if another lane wants it sooner, register on #3585 first.

PMAT-3459: port the release train's movable half — 7 declared path de…

Parked by APR-EPIC-001: over S1 budget (rank 32/163). Reopen = pull. Applied by aprender-d1: claude+agy both said close, apr shadow row recorded (handoff/close-quorum-2026-09-25.json).

PMAT-3459 (part 1): port the release train's movable half into script…

PMAT-3459 part 2: port the tag path into the repo — autopilot.sh + 2,…

PMAT-3587: fail-fast discards verdicts — the default flips, and skipp…

Navigation Menu

Repository navigation

7 scripts resolve the repo root with an unguarded 'git rev-parse --show-toplevel' — git refuses the container's bind-mounted tree, so a path question gets no answer #3586

The mechanism

Scope

The fix, which is the one tab 2 already applied

Positive control, and the technique is reusable

Ruling (operator): `|| pwd` is the wrong guard — the "guarded" sites are the deeper defect

What lands

Positive control, corrected

The acceptance predicate could be satisfied wrongly — fixing that before anyone starts

The stub, verbatim, so it is not lost in a session

Two notes from using it in anger

Acceptance, restated

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

7 scripts resolve the repo root with an unguarded 'git rev-parse --show-toplevel' — git refuses the container's bind-mounted tree, so a path question gets no answer #3586

Description

The mechanism

Scope

The fix, which is the one tab 2 already applied

Positive control, and the technique is reusable

Activity

noahgift commented on Sep 20, 2026

Ruling (operator): || pwd is the wrong guard — the "guarded" sites are the deeper defect

What lands

Positive control, corrected

noahgift commented on Sep 20, 2026

The acceptance predicate could be satisfied wrongly — fixing that before anyone starts

The stub, verbatim, so it is not lost in a session

Two notes from using it in anger

Acceptance, restated

noahgift commented on Sep 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Ruling (operator): `|| pwd` is the wrong guard — the "guarded" sites are the deeper defect