scripts: affected-tests.sh --run hangs on check-changed-skills.test.sh on Windows Git Bash

[kyle-sexton]

Summary

scripts/affected-tests.sh --run hangs on this Windows host when it reaches scripts/check-changed-skills.test.sh. Observed three times across the claude-ops plugin-sync work (PRs #3744, #3748, #3760, #3775): once at about 50 minutes, once at about 4 hours, once left indefinitely. No output after the suite name is printed; the process had to be killed by hand. The same suite passes in CI on every one of those PRs.

Steps to reproduce

1. Windows 11 Pro, Git Bash, Claude Code 2.1.261 to 2.1.263, a worktree of this repo with a claude-ops skill change staged.
2. Run scripts/affected-tests.sh --run.
3. Wait for scripts/check-changed-skills.test.sh to start.

Expected vs actual

• Expected: the suite finishes with a pass or fail line and the runner moves on.
• Actual: no further output, no CPU activity worth noting, the runner never returns.

Severity

Medium. It blocks the documented local validator on this host; the workaround is to run only the touched suites directly and treat CI as the statement of record. Not reproduced on Linux CI.

Suggested fix location

scripts/check-changed-skills.test.sh or whatever it shells out to that waits on stdin or a lock. Nothing was captured beyond the hang itself, so a first step is a per-case timeout or set -x trace inside that suite to name the blocking call.

Environment

Windows 11 Pro 10.0.26200, Git Bash, Claude Code 2.1.261 and 2.1.263.

[kyle-sexton]

This was generated by AI during triage.

Claimed for triage by autonomous lane instance vm-triage-202609050304. Lease expires 2026-09-06T19:40:00Z. This is a triage claim only, not an execution claim; the item stays unassigned and available to the worker lane once briefed.

---

Generated by Claude Code

[kyle-sexton]

This was generated by AI during triage.

Triage verdict

Category: Bug (real, not reproducible from this lane). State: briefed → human-gated. Work class: scoped. Priority: medium (matches reporter severity).

Verification (2026-09-06, against current main)

Not reproducible here, as expected: this lane runs on Linux and the suite completes normally. What triage could do was read the call chain the hang runs through, and that narrowed the suspect considerably. Findings below are static analysis, offered as a starting hypothesis rather than as a diagnosis.

The suite's own code is clean of the obvious causes. Every commit in the harness uses a non-interactive message flag, so no editor is ever opened. The shared git test helpers clear the inherited git environment at source time and force a throwaway identity with signing off, so nothing waits on a signing prompt or a credential helper. Every read loop in the suite and in the script under test is fed from a redirect or a here-string; none of them reads inherited stdin. The suite and the script it exercises contain no process substitutions at all.

The one construct that fits the symptom lives in the real checker, not in the suite. The suite stubs the skill checker for most scenarios, but three of its cases stage the real check-skill.sh into the fixture and run it. That script contains five process substitutions of the done < <(...) form. Process substitution is the classic construct that hangs indefinitely with no CPU on MSYS2 / Git Bash, because it is implemented over /dev/fd FIFOs whose semantics differ from Linux; a reader that never sees EOF simply blocks forever. That signature matches the report exactly: no further output, negligible CPU, never returns.

That gives a concrete first probe: the hang is likely in one of the three integration cases that stage the real checker, inside a process substitution, not in the suite's own stub cases. If the operator can get a trace, the expectation is that the last line before the stall sits at or just before one of those < <(...) reads.

A second, cheaper hardening lever, independent of the above. The runner invokes each selected suite as a plain bash <suite> with stdin inherited from the operator's terminal. Nothing found in this chain reads inherited stdin today, so this is not the current cause, but it means any future suite that does will hang the whole runner with no diagnostic. Redirecting suite stdin from the null device costs nothing and removes an entire class of this failure permanently.

Why human-gated rather than agent-ready

Capability blocker: both reproduction and verification of the fix require the Windows 11 Git Bash host. An agent on Linux cannot observe the hang, cannot confirm which call blocks, and, most importantly, cannot verify that any change actually fixed it. A fix shipped on the strength of the hypothesis above, verified only by a still-green Linux suite, would be indistinguishable from no fix at all.

The one exception is the stdin hardening, which is verifiable on any host and is worth taking regardless of what the trace shows.

What the human at the Windows host should do, in order

1. Name the blocking call. Re-run the runner and, when it stalls, get a trace out of the suite (a shell execution trace, or per-case progress output). The goal is a single answer: which command was executing when it stopped. Everything after this is cheap; without it, any fix is a guess.
2. Confirm or refute the process-substitution hypothesis. Run the three real-checker integration cases directly, outside the runner. If they hang and the stub-only cases do not, the suspect is confirmed and the fix belongs in the checker (replace the process substitutions with a temporary-file or here-string feed, which behaves identically on both hosts).
3. Bound the failure so it can never again cost four hours. A per-suite timeout in the runner that fails loudly with the suite's name beats an indefinite stall, whatever the root cause turns out to be. This is the change that converts the worst case from "left overnight" into "one failed line".
4. Take the stdin hardening while in the file.

Acceptance criteria

• The blocking call is named in this issue, with the trace or the narrowing that identified it.
• The suite completes on the Windows Git Bash host, run both directly and through the runner, and still passes on Linux.
• A suite that stalls is bounded by a timeout that reports which suite stalled, rather than hanging the runner indefinitely.
• Suites are invoked with stdin detached from the terminal, so a stdin-reading suite fails fast instead of hanging.
• If the cause turns out to be a construct with a known cross-platform hazard, every other occurrence of that construct in the repo's own scripts is inventoried, and either changed or explicitly recorded as safe.

Out of scope

• The unrelated Windows Git Bash slowness of the local gates tracked in perf(scripts): local gate scripts take minutes on Windows Git Bash (check-skill, changelog-parity --check-bump, affected-tests, em-dash purge, check-open-questions --brief) #3717. Same host, different question; do not fold them.
• Rewriting the runner's suite-selection logic. The selection is correct; the suite it selects is what stalls.
• Changing what the skill checker checks. Only how it feeds its own read loops, if that is where the trace lands.

Note for whoever picks this up

The process-substitution lead above is a hypothesis from reading the code, not an observation. Step 1 exists precisely so it gets confirmed or discarded on evidence. Do not skip to step 2's fix on the strength of this comment.

Triage claim released by vm-triage-202609050304.

---

Generated by Claude Code

[kyle-sexton]

This was generated by AI during triage.

Reproduced on the Windows Git Bash host — root cause named, hypothesis refuted

The prior triage comment's step 1 ("name the blocking call") is done. This pass ran on the Windows 11 Git Bash host the report came from.

Provenance note: the working tree used for the reproduction sat on fix/clean-batch-single-instance-guard, which trails main in these files. The defective function is byte-identical on origin/main, and main's copy of the suite carries more of the affected integration cases (6 stage_checker sites vs 3), so the finding transfers directly. All line numbers below are origin/main.

Reproduction

bash scripts/check-changed-skills.test.sh run directly, outside the runner, hangs. Killed at a 300s hard timeout, having burned ~1.5s user / ~1.7s CPU. So affected-tests.sh --run is not the cause and is not part of the fix; the suite hangs on its own.

Under bash -x, the trace stops at the first integration case that stages the real checker — the "new skill without evals fails the changed-skill gate" case. Its subshell redirects >/dev/null 2>&1, which is why the xtrace goes silent exactly there: the hang is inside the real checker, not in the suite.

The blocking call

evals_warrant_exemptions_file() in the skill-quality checker — plugins/skill-quality/scripts/check-skill.sh:828-837, all line numbers in this comment against origin/main — walks up from the repo root looking for scripts/evals-warrant-exemptions.txt:

while [[ -n "$d" && "$d" != "/" ]]; do
  if [[ -f "$d/scripts/evals-warrant-exemptions.txt" ]]; then ...; fi
  d="$(dirname "$d")"
done

The loop terminates only on empty or /. On Git Bash, REPO_ROOT comes back from git rev-parse --show-toplevel as a drive-letter path, and MSYS path conversion means the walk reaches a drive root rather than /. Measured on this host:

dirname /tmp   -> /
dirname C:/    -> C:
dirname C:     -> C:      <-- fixed point

C: is neither empty nor /, so the loop spins forever, forking /usr/bin/dirname each iteration. The bash -x log grew to 40,495 lines of the same four-line cycle before the timeout fired.

Why it only bites here. The walk is only exhausted when scripts/evals-warrant-exemptions.txt is absent up the entire chain. In the real checkout it exists and the function returns on iteration 1 — check-skill.sh against a real skill completes in 4.6s on this same host. Only the suite's throwaway fixture repos lack the file, and only those cases hang. On Linux the walk terminates because dirname / -> /. That is exactly why CI is green on every one of #3744, #3748, #3760, #3775 and why the checker looks fine when run by hand.

"No CPU activity" is consistent, not contradictory: the cost is fork-per-iteration of a short-lived external dirname, which never accumulates against the parent shell's own CPU accounting.

The process-substitution hypothesis is refuted

The prior comment flagged done < <(...) in the real checker as the suspect and asked for confirmation before anyone acted on it. Confirmed refuted: the seven process substitutions in that file are all reached and all complete. Neither scripts/check-changed-skills.test.sh nor scripts/check-changed-skills.sh contains a process substitution at all. Nothing in this chain reads inherited stdin.

Fix, verified on this host

Add the fixed-point guard the rest of this repo already uses — e.g. plugins/markdown-format/hooks/markdown-format.sh:559-561, plugins/bash-format/hooks/bash-format.sh:178-180, plugins/ruff-format/hooks/ruff-format.sh:186-188 all carry it:

parent="$(dirname "$d")"
[[ "$parent" == "$d" ]] && break
d="$parent"

Applied to a patched copy (working tree untouched) and re-run on this Windows host:

• Minimal fixture, direct checker call: hang -> 2.4s, and it returns the correct verdict (FAIL — 1 error(s), the missing-evals failure the case asserts).
• Full suite scripts/check-changed-skills.test.sh: hang -> PASS=15 FAIL=0 in 9.7s.

Prior acceptance criteria status

• Blocking call named, with the narrowing that identified it — above.
• Cross-platform-hazard inventory (criterion 5). Grepping by termination condition rather than variable name, check-skill.sh:830 is the only dirname walk-up loop in the repo that terminates on / without a fixed-point guard. Every sibling loop already has the guard. One latent near-miss to record but not change: plugins/claude-ops/hooks/claude-ops-paths.sh:32-34 also lacks the guard, but its [[ ! -e "$ancestor" ]] condition terminates it at a drive root, so it is safe today.
• Suite passes on Windows and Linux — verified on Windows against a patched copy; needs the change in tree.
• Per-suite timeout in the runner so a stall names its suite instead of hanging indefinitely.
• Suites invoked with stdin detached.

The last two remain worthwhile hardening, but they are separable from the fix and no longer on its critical path.

Regression test runs anywhere

dirname . -> . on GNU coreutils too, so the same fixed point is reachable on Linux by calling the function with a relative path. A regression test for this does not need a Windows runner.

Re-routing: needs-human -> agent-ready

The prior triage gated this on a capability blocker: an agent could not observe the hang, could not confirm which call blocks, and could not verify a fix. All three are now discharged with evidence from the affected host. What remains is a one-line guard in one file, reusing an idiom already established in five other scripts in this repo, plus a regression test that runs on any platform. work-class: scoped and priority: medium stand.

---

Generated by Claude Code