babysit-prs engine.test.sh: 3 python-cli refusal rows fail only when a local uv python3 shim leaks PYTHONHOME into the wrappers' py -3 — not a repo bug; passes on Linux CI

[kyle-sexton]

plugins/source-control/skills/babysit-prs/scripts/engine.test.sh fails on clean main.
Reproduced at 9f73fc2e with no working-tree changes:

FAIL: test_every_refusal_row (test_guards.RefusalsFireOnArgumentShape.test_every_refusal_row)
      (row='merge.wrapper-reaches-failclosed-cli')     AssertionError: 1 != 3
      (row='resolve.wrapper-reaches-failclosed-cli')   AssertionError: 1 != 3
      (row='resolve.wrapper-filters-nothing')          AssertionError: 1 != 2

FAILED (failures=3)

The three rows assert a specific exit code from the guarded wrapper and get 1 instead of the
expected 3 / 2.

Why main looks green

scripts/check-changed-skills.sh runs a skill's script tests only when that skill changes.
babysit-prs has not changed recently, so the gate has not executed engine.test.sh and the
failure has stayed latent.

It surfaces on the next PR that touches babysit-prs for any reason — including a
documentation-only edit, which is how it was found (#1619 pre-compute migration). That PR then
inherits a red gate it did not cause.

Why this matters beyond the noise

The failing rows are all fail-closed refusal assertions — wrapper-reaches-failclosed-cli for both
the merge and resolve wrappers, and resolve.wrapper-filters-nothing. These are exactly the tests
that are supposed to prove the merge/resolve guards refuse rather than fall through. An exit code of
1 where 3 is expected means either the guard is exiting on a different path than the contract
says, or the test's expectation has drifted from the wrapper. Which of those it is has not been
determined — this issue reports the failure, it does not diagnose it.

Note the same run's own inline checks all pass (merge wrapper rejects --allow-unpinned-head,
… reaches fail-closed CLI (no allowlist), and the rest), so the wrappers are refusing something
correctly. The disagreement is narrower than "the guard is broken", which is why it needs a real
look rather than a re-baselined assertion.

Ask

1. Determine whether the wrapper's exit code or the test's expectation is wrong. Do not simply
   update the expected value to 1 — if the wrapper's fail-closed path changed, that is the finding.
2. Once fixed, consider whether a latent-test-failure sweep belongs in CI. A gate that only runs on
   changed paths will keep accumulating this class silently; a periodic --all run would catch it.

Related

• Found while preparing the fix(skills): worktree-isolated agents cannot invoke a skill whose pre-compute block contains a $-expansion (21 skills; NOT git — see correction comment) #1619 pre-compute migration for source-control; that PR changes only
  SKILL.md prose and reference docs, touches no engine code, and deliberately does not fix this.
• chore(source-control): babysit-prs/SKILL.md also sits 1 line under the 500-line hard cap #1626 — separate babysit-prs line-cap issue, unrelated.

[kyle-sexton]

Correction from the reporter: main is not red — this is a local-environment artifact

I filed this. Re-verification says the central premise is wrong, so I am correcting it rather than
leaving it to mislead whoever picks it up. No repo code is at fault, and the changed-skills gate
did run this test. Details, with what is confirmed vs inferred marked.

1. CI did execute engine.test.sh, on Linux, and it passed (confirmed)

The issue claims "the gate has not executed engine.test.sh and the failure has stayed latent."
That is falsified. PR #1679 touches babysit-prs, so scripts/check-changed-skills.sh selected it,
and check-skill.sh Check 7 ran the script tests. Run 30230364599, job skill-quality-gate
(id 89867992626, ubuntu-24.04), conclusion success. Verbatim from the job log, inside the
=== plugins/source-control/skills/babysit-prs === section:

2026-07-27T01:41:16.5294380Z === plugins/source-control/skills/babysit-prs ===
2026-07-27T01:41:20.0489836Z INFO: script test passed: scripts/engine.test.sh
2026-07-27T01:41:20.5488639Z CHECK-SKILL babysit-prs: PASS — 0 errors, 1 warning(s)

That is positive evidence of execution, not merely a green job.

2. The Windows failure is real and still reproduces (confirmed)

At 444ef281, clean tree, bash plugins/source-control/skills/babysit-prs/scripts/engine.test.sh:

FAIL: test_every_refusal_row (test_guards.RefusalsFireOnArgumentShape.test_every_refusal_row) (row='merge.wrapper-reaches-failclosed-cli')
AssertionError: 1 != 3 :
GUARD CONTRACT ROW `merge.wrapper-reaches-failclosed-cli` NO LONGER HOLDS.
  observed: exit 1:

Traceback (most recent call last):
  File "...\scripts\babysit_merge.py", line 49, in <module>
    from dataclasses import dataclass
  File "C:\Users\<user>\AppData\Roaming\uv\python\cpython-3.14-windows-x86_64-none\Lib\dataclasses.py", line 5, in <module>
    import inspect
  File "C:\Users\<user>\AppData\Roam
...
Ran 442 tests in 25.945s
FAILED (failures=3)

The exit-1 rows are not a guard misbehaving. They are a Python interpreter that cannot import its
own stdlib. The original report never saw that, because test_guards.py:183 truncates the observed
output with combined[:400] and the traceback tail was cut off.

3. Root cause: a PYTHONHOME leak from a uv python3 shim (confirmed)

engine.test.sh selects its interpreter as the first working python3/python on PATH. On this
machine that is uv's trampoline ~/.local/bin/python3.exe. That trampoline exports PYTHONHOME
into its own environment, and every child process inherits it. The differential:

# ambient Git Bash environment — no PYTHONHOME at all
$ env | grep -E '^PYTHON'
(no output)

# inside the python3 the test suite runs under
$ python3 -c "import os; print(os.environ['PYTHONHOME']); print(os.environ['UV_INTERNAL__PYTHONHOME'])"
C:\Users\<user>\AppData\Roaming\uv\python\cpython-3.14-windows-x86_64-none
C:\Users\<user>\AppData\Roaming\uv\python\cpython-3.14-windows-x86_64-none

So it is not a globally-set PYTHONHOME — the shim injects it.

test_guards.invoke() runs wrapper rows as [bash, <wrapper>, ...], inheriting that environment.
The wrapper sources babysit-python.sh, whose babysit_python() prefers py -3 — and on this
machine py -3 is a different interpreter from the one running the suite:

$ py -0p
 -V:3.13 *        C:\Users\<user>\AppData\Local\Programs\Python\Python313\python.exe
 -V:Astral/CPython3.14.3 C:\Users\<user>\AppData\Roaming\uv\python\cpython-3.14.3-windows-x86_64-none\python.exe

A 3.13 binary then honours the inherited PYTHONHOME and loads 3.14's stdlib:

$ PYTHONHOME='...\cpython-3.14-windows-x86_64-none' py -3 -c "import dataclasses"
  File "...\cpython-3.14-windows-x86_64-none\Lib\annotationlib.py", line 0
SyntaxError: invalid syntax (annotationlib.py, line 327)

That is exit 1, before babysit_merge.py / babysit_resolve_thread.py reach any argument parsing —
hence 1 where the contract expects 3 / 2.

Two controls, both at 444ef281 on the same clean checkout, back to back (this rules out any
"CI ran newer code" explanation):

run	interpreter	result
engine.test.sh (picks the uv python3 shim → PYTHONHOME leaks)	mixed 3.14 shim / py -3 3.13	Ran 442 tests — FAILED (failures=3)
same suite via the real ...\cpython-3.14-windows-x86_64-none\python.exe (no PYTHONHOME injected)	3.14 throughout	Ran 442 tests — OK

And stripping only PYTHONHOME from the child environment makes the wrapper reach the CLI normally
(exit 2 for the ad-hoc argv I used, i.e. argparse, i.e. Python was entered) instead of exit 1.

4. The failing set is exactly what the diagnosis predicts (confirmed)

guard_contract.py has 7 refusal rows with a bin/ entry point. Four are refused_by='bash-wrapper'
— they never reach Python, so a broken interpreter cannot touch them. Three are
refused_by='python-cli'. Those three, and only those three, are the failures:

row	refused_by	result here
merge.unpinned-head-refused-by-wrapper	bash-wrapper	pass
merge.abbreviated-unpinned-head-refused-by-wrapper	bash-wrapper	pass
merge.equals-value-unpinned-head-refused-by-wrapper	bash-wrapper	pass
merge.equals-value-abbreviated-unpinned-head-refused-by-wrapper	bash-wrapper	pass
merge.wrapper-reaches-failclosed-cli	python-cli	fail (1 != 3)
resolve.wrapper-reaches-failclosed-cli	python-cli	fail (1 != 3)
resolve.wrapper-filters-nothing	python-cli	fail (1 != 2)

This also explains the puzzle noted in the original issue — that engine.test.sh's own inline
== guarded-wrapper behavior == checks all pass. Those run from the shell directly, with no
PYTHONHOME in the environment, so their subprocesses get a coherent interpreter.

5. Why Linux CI cannot hit this (inferred from mechanism, not from CI's environment)

I did not inspect the runner's environment. But py is the Windows Python launcher and does not
exist on ubuntu-24.04, so babysit_python() falls through to python3 — the same interpreter
engine.test.sh itself selected. Parent and child are then the same binary, so a binary/stdlib
mismatch is not constructible there, PYTHONHOME present or not. The precondition is
machine-specific, not merely OS-specific: it needs both a python3 shim that exports
PYTHONHOME and a py -3 resolving to a different Python version. A Windows box with a single
Python install would not reproduce this.

6. What survives from the original issue

Falsified:

• "fails on clean main" as a repo-wide statement — no, it fails on my machine only.
• "the gate has not executed engine.test.sh" — it has, on fix(source-control): move git out of skill pre-compute so worktree-isolated agents can invoke these skills #1679, and it passed.
• "it surfaces on the next PR that touches babysit-prs" — fix(source-control): move git out of skill pre-compute so worktree-isolated agents can invoke these skills #1679 touches it and is green.
• The priority: high label was applied on the "main is red" premise. That premise is gone.

Not falsified, and worth keeping on their own merits:

• The changed-skills-only gating mechanic is accurately described; it would let a genuine latent
  failure hide.
• Ask fix: correct plugin-system inaccuracies and harden references #2 — a periodic --all sweep — stands independently of this report being wrong.

7. Two smaller, genuinely-in-repo observations (separate from the above; neither causes any CI-visible failure)

Recording these as candidates only; I am not asserting either needs a change.

1. _babysit_probe_python() in scripts/babysit-python.sh probes with
   -c 'import sys; raise SystemExit(...)'. Under a PYTHONHOME-poisoned interpreter that probe
   still exits 0 — I verified it — so the interpreter is accepted and then dies on the first
   real stdlib import. The function's own comment says it probes by running candidates precisely
   because Windows ships interpreters that resolve on PATH yet fail at launch; this is a nearby
   failure mode the current probe does not cover. Whether the wrappers should also prefer the
   caller's interpreter over py -3 is a design question, not a bug I am claiming.
2. test_guards.py:183 truncates observed output at combined[:400], which cut off the traceback
   that would have identified this in minutes.

Ask

Retitling to reflect the real scope. Not closing it — a maintainer should decide whether anything in
§6 or §7 is worth keeping open, and drop priority: high if not.

Apologies for the noise; the original framing was mine and it was wrong.

[kyle-sexton]

Addendum — closing a gap in §1's evidence chain

§1 above asserted that INFO: script test passed: scripts/engine.test.sh is "positive evidence of
execution." That line alone does not actually carry that weight, and the same standard I applied to
the original report applies here. Check 7 of check-skill.sh is:

if env -u GIT_DIR ... bash "$test_sh" >/dev/null 2>&1; then
  note "script test passed: ${test_sh#"$SKILL_DIR"/}"

It reports passed on any exit 0 — and engine.test.sh has an exit-0 SKIP path:

if [[ -z "$PY" ]]; then
  echo "SKIP: Python 3.11+ not found"
  exit 0
fi

Since the script's stdout is sent to /dev/null, a SKIP would be indistinguishable from a pass in
the job log. So the question is whether the runner had a Python 3.11+ on PATH as python3 or
python at that moment. Two facts close it:

1. The Python setup in this job runs after the gate step. uv/UV_PYTHON: 3.14 first appears
   at 01:41:24.62; check-changed-skills.sh ran 01:41:16.43–01:41:24.45. So the gate could
   only have used the image's preinstalled interpreter.
2. That preinstalled interpreter is Python 3.12.3. The log names the exact image
   (Image: ubuntu-24.04, Version: 20260720.247.2) and links its software manifest; that manifest
   lists Python 3.12.3 under Language and Runtime. 3.12.3 ≥ 3.11, so engine.test.sh selects it
   and the SKIP branch is not reachable.

Corroborating but not load-bearing: the babysit-prs script test occupied 01:41:16.58→01:41:20.05,
about 3.5s — consistent with running 442 tests, and far too slow for a SKIP (the commit skill's
much smaller exec-bit-check.test.sh took ~1.1s in the same run).

So §1 stands: the suite genuinely executed on Linux and passed. Incidentally, ruff is not on that
image, so the lint pass inside engine.test.sh does take its own SKIP on CI — harmless, but it means
CI's green covers the unittest suite and the bash wrapper checks, not the lint pass.

Nothing else in the comment above changes. The headline verdict never rested on the CI claim anyway:
the same checkout passes 442/442 locally once the interpreter is coherent.

[kyle-sexton]

Closing as not a repository defect — issue title and body state this explicitly.

Evidence: Issue documents that the 3 engine.test.sh python-cli refusal rows fail only when a local uv python3 shim leaks PYTHONHOME into the wrappers' py -3 path, and passes on Linux CI. No code change required on main.