Windows: verify env-fault classification never fires — cmd reports missing/non-executable tools as 9009/1, not 126/127

[dracic]

Summary

ENV_FAULT_RCS = frozenset({126, 127}) (src/bmad_loop/verify.py:1376) encodes the sh launcher convention: 126 = found but not executable, 127 = not found. run_verify_commands runs commands with shell=True, so on Windows the shell is cmd, which never uses those codes — a missing executable is 9009 ("is not recognized as an internal or external command") and a non-executable one typically surfaces as 1.

The consequence is that on Windows the env-fault arm at verify.py:1410 is unreachable in practice. A broken verify environment is classified an ordinary fixable failure, so the run dispatches repair sessions and burns dev attempts against a tree no session can fix — precisely the failure #126 was filed for and #130 fixed on POSIX.

The comment at verify.py:1374-1375 states the gap ("Windows cmd signals these as 9009/1 instead, so it keeps the charged behavior") but nothing tracks closing it.

Evidence

The three engine tests that pin this behavior are all win32-skipped for exactly this reason:

• test_review_verify_env_fault_escalates_instead_of_fix_session
• test_skip_review_env_fault_escalates_not_defers
• test_fix_phase_env_fault_escalates_instead_of_looping

each carrying @pytest.mark.skipif(sys.platform == "win32", reason="sh env-fault exit codes (cmd reports 9009)"). So the Windows behavior is neither correct nor exercised.

Why this is not a trivial patch

Adding 9009 is safe and unambiguous. Adding 1 is not — under cmd, rc 1 is also the ordinary "the tests failed" code, which is exactly the fixable failure that should route to a repair session. Classifying it an env fault would pause runs on every genuine test failure on Windows.

So the fix needs a decision on how far to go, roughly:

1. 9009 only — narrow, no false positives, catches the common "tool not on PATH" case, leaves non-executable files charged.
2. 9009 + a stderr probe — treat rc 1 as an env fault only when the output tail matches cmd's not-recognized/access-denied phrasing. Catches more, but pattern-matches localized shell text.
3. Bypass the shell for env detection — resolve the command's leading token before running it and classify unresolvable ones without relying on the shell's exit code at all.

Whatever is chosen, ENV_FAULT_RCS stops being a platform-neutral frozenset and becomes a per-shell classifier; the three skips above should be lifted as part of the change so the Windows path is actually pinned.

Refs

• Worktree seeding drops file modes; verify rc=126/127 is charged as a story failure #126 (seeded worktrees losing +x burned dev attempts), fix: preserve seed file modes + pause on verify env faults (rc 126/127) #130 (the POSIX fix)
• Surfaced during the Windows: env-fault engine test replays check.sh through cmd — pops the 'How do you want to open this file?' dialog on every local full-suite run #292 review, which touched a sibling test in the same area but deliberately left this behavior alone

[coderabbitai]

🔗 Related PRs

#98 - fix(platform): harden win32 atomic replaces and path segments [merged]
#103 - fix(platform): overwrite-safe deferred stash + ref-safe unit branch names [merged]
#130 - fix: preserve seed file modes + pause on verify env faults (rc 126/127) [merged]
#272 - fix(#194): pause on coding-CLI transport failures instead of burning story/sweep attempts [merged]
#301 - test(win32): build the env-fault verify script for the host shell (#292) [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[dracic]

Correction: cmd /c reports a missing tool as rc 1, not 9009

Measured on Windows 11 (26200), COMSPEC=C:\Windows\system32\cmd.exe, which is exactly how
run_verify_commands invokes a verify command (subprocess.run(..., shell=True)):

subprocess.run("definitely-not-a-tool-xyz", shell=True)   -> rc=1
  stderr: 'definitely-not-a-tool-xyz' is not recognized as an internal or external command
cmd /c definitely-not-a-tool-xyz                          -> exit 1
cmd /c "definitely-not-a-tool-xyz && echo x"              -> exit 1

9009 exists, but only inside a batch file, as %ERRORLEVEL% — it reaches us only when the
verify command is a .cmd/.bat that propagates it:

probe.cmd: @echo off / definitely-not-a-tool-xyz / echo INSIDE_ERRORLEVEL=%ERRORLEVEL% / exit /b %ERRORLEVEL%
cmd /c probe.cmd -> INSIDE_ERRORLEVEL=9009, exit 9009

So option 1 ("9009 only") does not fix the reported case. The common
"pytest is not on PATH" fault arrives as rc 1 — indistinguishable by exit code from the
ordinary "tests failed" that must route to a repair session. The real choice is between the
stderr probe (option 2) and resolving the leading token (option 3).

Second finding: on win32 a non-executable verify command is a silent false pass, not a charged attempt

Same probe, cmd /c <path> where the path is not executable by cmd (extension not in PATHEXT):

cmd /c C:\tmp\check.sh    -> rc=0, no output   (handed to the file association; the script never ran)
cmd /c C:\tmp\plain.txt   -> rc=0, no output

This is the win32 counterpart of the rc 126 case the issue is about (the POSIX
_self_disarming_script fault), and it is worse than a charged attempt: verify reports
passed for a check that never executed. shutil.which() returns None for both paths
(PATHEXT has no .SH/.TXT), so a resolvability probe classifies it without any exit-code or
message dependency — the same mechanism option 3 needs. Related to #292 / #301, which fixed the
test-side symptom of the same cmd-launcher semantics.

Consequence for the fix

ENV_FAULT_RCS becoming a per-shell classifier stands, but the win32 arm cannot key on the exit
code at all: it needs the stderr signature and a resolvability probe (localized Windows does
not print the English "is not recognized" phrasing, and the false-pass case carries rc 0 with no
output). Keeping 9009 is still worth it — zero false positives, and it covers the batch-wrapper
case above.