main is red on both platforms across all four completed runs: plugin_e2e_acceptance on macOS, NSIS provisioning on Windows

[Lstarsky0]

Now that #5395 stopped main runs from cancelling each other, they complete — and the four that have completed since are red on both platforms. Posting the set because the verdicts are new information rather than a new breakage.

commit	macOS	Windows
ee1f9cb9e	agy_credentials ×4	NSIS install
dd0fbed81	agy_credentials ×4	NSIS install
ad102ec44	plugin_e2e_acceptance	NSIS install
5ac75add4	plugin_e2e_acceptance	NSIS install

Two separate causes, and neither is a flake.

macOS — plugin_e2e_acceptance was hiding behind the agy failures

test plugin_e2e_acceptance::plugin_toml_binary_lifecycle_skill_and_stdio_mcp_acceptance ... FAILED
test result: FAILED. 25 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 82.49s

The macOS leg has been red on every run; what changed at ad102ec44 is only which test reports it. #5396 fixed the four agy_credentials cases, and this one surfaced underneath.

It also fails on an unmodified main here — it is in the failure set of a full cargo test --workspace --all-features --locked --no-fail-fast I ran on a clean checkout.

The cleanest evidence that it is not anyone's diff: two of my open PRs sit on the same base with completely unrelated changes — #5397 is four Simplified Chinese copy files, #5398 is one generated TypeScript data file — and both fail this same test with the identical 25 passed; 1 failed.

Windows — a required check installs NSIS from Chocolatey at test time

Four for four, same step, two different Chocolatey symptoms:

Failed to fetch results from V2 feed at 'https://community.chocolatey.org/api/v2/Packages(Id='nsis',Version='3.12.0')'
  with following message : Response status code does not indicate success: 504 (Gateway Timeout).

nsis not installed. The package was not found with the source(s) listed.

and then, both times:

Exception: scripts\installer\installer-path-regression.tests.ps1:80
  throw 'makensis.exe was not found after installing NSIS.'

The job never reaches the Rust tests — the logs are under 200 lines and contain no test results at all. So Test (windows-latest) currently reports on Chocolatey's availability rather than on the code, and it is a required check, so every contributor's PR inherits it. Mine did: #5397's first Windows run was the 504, and a re-run after rebasing passed cleanly, which is the shape of an external dependency rather than anything in the tree.

Pinning the NSIS version to a cached artifact, or skipping the installer path regression when makensis cannot be provisioned, would both stop an outage at a third-party feed from reading as a red build. Which of those you want is a call about how much the check is meant to guarantee, so I have not sent a patch.

Happy to split this into two issues if you would rather track them apart — I kept them together because "what is main failing right now" is one question.

[github-actions]

Thanks @Lstarsky0 for the report.

This issue is staying open for maintainer triage. CodeWhale gets better because people bring us real edge cases from real machines, providers, regions, and workflows.

If you can add a reproduction, logs, version output, screenshots, or the provider/model involved, that makes it much easier for us to verify and harvest the fix. Maintainers may comment /lgtmi to mark recurring issue reporters as approved so this intake note is skipped next time.

[Hmbown]

Current state check (2026-08-16, receipts) — both cited causes are green on the latest main run at 4b40ecbe0 (CI run 31967912516, completed 2026-08-16T20:26Z, all executed jobs success):

macOS — the exact test this issue cites passed:

PASS [   6.686s] (12199/12880) codewhale-tui::cucumber plugin_e2e_acceptance
     ::plugin_toml_binary_lifecycle_skill_and_stdio_mcp_acceptance

(from gh run view --job=95215808980 --log, Test (macos-latest), 2026-08-16T19:54:03Z)

This test is on the repo's known-flake list (macOS plugin_e2e_acceptance / agent_focus_pty — policy is rerun-once before investigating), and the reliability work is tracked in #5056. Your evidence that it failed on an unmodified clean checkout is consistent with an intermittent test rather than a diff-caused break, but #5056 is where that gets fixed properly.

Windows — Test (windows-latest) green on the same run; the Chocolatey 504 / package-not-found symptoms in the report are an external-feed outage, and the leg recovered when the feed did (matches the rebase-rerun-passes shape you observed).

What remains is a real decision, not a breakage: your NSIS hardening ask — pin NSIS to a cached artifact vs. skip the installer-path regression when makensis can't be provisioned. That's a maintainer call about how much the required check is meant to guarantee against third-party feed outages; neither has been patched.

Proposed disposition (maintainer's call): the "main is red" claim is stale — both platforms are green at 4b40ecbe0. The macOS flake folds into #5056; the NSIS hardening is worth its own issue if you want it tracked separately, or this issue can stay open scoped to just that decision. cc @HmbownBown.

[Hmbown]

Rolled to v0.9.10: the v0.9.9 release branch merged to main tonight (#5476) without this landing; nothing here is closed or dropped.

[Hmbown]

Both platforms are addressed; closing.

macOS — root cause found, not papered over. 4abca3602 ("test(tui): stop macOS plugin PTY fixture hanging on keep-alive"): the fixture's tiny_http read used read_to_string, which waits for EOF, so with reqwest's HTTP/1.1 keep-alive the first chat POST never completed — matching the finished in 82.49s you tabulated. Fixed with Content-Length-only reads plus Connection: close. All four red commits you listed are from 2026-08-14, i.e. before that landed.

Windows — a third option, deliberately. Neither of the two you proposed (pin a cached NSIS artifact, or skip when unprovisionable). ci.yml now wraps choco install nsis in a three-attempt backoff (0/20/45s) that fails loudly after all three, and installer-path-regression.tests.ps1 still hard-requires makensis. The reasoning is in the step comment: this survives a transient Chocolatey outage without weakening the check, and the installer regression must not silently skip.

If Chocolatey outages start surviving three attempts, that is a new issue about pinning a cached NSIS artifact rather than this one.