CI outage: all Rust workflows startup_failure since 2026-08-14 04:00 UTC — Actions allowlist blocks dtolnay/rust-toolchain, Swatinem/rust-cache, stefanzweifel/git-auto-commit-action

[logbie]

Summary

All Rust CI on this repo has been failing at startup since ~04:00 UTC today (2026-08-14). Nightly Build, CI, Auto Format and WFL Config Lint all return startup_failure ("This run likely failed because of a workflow file issue") with zero jobs created, on main and on every PR branch.

This is not a workflow-file bug. No workflow file changed. The cause is the repository/organization Actions allowlist, which is currently set to selected with only two permitted third-party patterns.

Evidence

Current policy — identical at repo and org level:

// GET /repos/WebFirstLanguage/wfl/actions/permissions
{ "enabled": true, "allowed_actions": "selected" }

// GET /repos/WebFirstLanguage/wfl/actions/permissions/selected-actions
{
  "github_owned_allowed": true,
  "verified_allowed": true,
  "patterns_allowed": ["actions/checkout@v5", "peter-evans/create-pull-request@v8"]
}

GET /orgs/WebFirstLanguage/actions/permissions returns the same selected + same two patterns, so this affects every repo in the org, not just this one.

A workflow that references any action outside that set is rejected before a runner is ever assigned, which is exactly the startup_failure signature.

The split lines up perfectly:

Workflow	Third-party actions used	Status today
nightly.yml	dtolnay/rust-toolchain@stable, Swatinem/rust-cache@v2	❌ startup_failure
ci.yml	dtolnay/rust-toolchain@stable ×7, Swatinem/rust-cache@v2 ×6	❌ startup_failure
auto-fmt.yml	dtolnay/rust-toolchain@stable, stefanzweifel/git-auto-commit-action@v5	❌ startup_failure
wfl-config-lint.yml	dtolnay/rust-toolchain@stable	❌ startup_failure
versioning.yml	dtolnay/rust-toolchain@stable	❌ (would fail; not triggered since)
update-security-doc.yml	peter-evans/create-pull-request@v8 — allowlisted	✅ success
claude.yml / claude-code-review.yml	anthropics/claude-code-action@v1 — passes via verified_allowed	✅ success
CodeQL / Copilot	GitHub-owned	✅ success

actions/checkout@v4, actions/setup-python@v4, actions/setup-node@v4, actions/{upload,download}-artifact@v4 are all fine — github_owned_allowed: true covers them regardless of the pinned @v5 pattern.

Bisection

Time (UTC)	SHA	CI	Auto Format
03:31:44	98446d10	✅ success	✅ success
04:04:49	82b3fc36	—	— (update-security-doc ❌ on the pre-bump action versions)
04:06:21	82b3fc36	—	— (update-security-doc ✅ after the versions matched the allowlist)
04:28:57	14475196	❌ startup_failure	❌ startup_failure
… every run since		❌	❌

Every run before ~04:00 is green; every run after is startup_failure. Nothing in ci.yml, nightly.yml, auto-fmt.yml or wfl-config-lint.yml was edited in that window — #689 touched only claude-code-review.yml and update-security-doc.yml. The update-security-doc.yml pair at 04:04/04:06 on the same SHA (fail, then pass once its actions matched @v5/@v8) is the clearest single datapoint that the allowlist, not the code, is the gate.

The last successful nightly is 2026-08-13 (run 31670830424, sha 6609c813). Today's nightly (31773451896, sha 98d11b9f) is the first red one.

Impact

• No build, test, clippy, fmt, integration, DB, fuzz-compile, TestPrograms or config-lint coverage on main or on any PR since 04:00 UTC.
• PR Consolidate test helpers into tests/common/mod.rs #694 currently shows a red X for this reason and is not the author's fault.
• No nightly artifacts published today.
• Probably affects Scriptorium, wfl-web, Scribe and the other org repos too, since the policy is org-level.

Fix

Someone with org-owner rights needs to do one of the following. Option A is the minimal, security-preserving fix — it keeps the allowlist and adds only what the repo already uses:

# Org level (this is the binding one — repos cannot loosen beyond it)
gh api -X PUT orgs/WebFirstLanguage/actions/permissions/selected-actions \
  -F github_owned_allowed=true -F verified_allowed=true \
  -f 'patterns_allowed[]=actions/checkout@v5' \
  -f 'patterns_allowed[]=peter-evans/create-pull-request@v8' \
  -f 'patterns_allowed[]=dtolnay/rust-toolchain@*' \
  -f 'patterns_allowed[]=Swatinem/rust-cache@*' \
  -f 'patterns_allowed[]=stefanzweifel/git-auto-commit-action@*'

# Repo level (currently mirrors the org list)
gh api -X PUT repos/WebFirstLanguage/wfl/actions/permissions/selected-actions \
  -F github_owned_allowed=true -F verified_allowed=true \
  -f 'patterns_allowed[]=actions/checkout@v5' \
  -f 'patterns_allowed[]=peter-evans/create-pull-request@v8' \
  -f 'patterns_allowed[]=dtolnay/rust-toolchain@*' \
  -f 'patterns_allowed[]=Swatinem/rust-cache@*' \
  -f 'patterns_allowed[]=stefanzweifel/git-auto-commit-action@*'

Option B (revert to the pre-04:00 posture, less selective):

gh api -X PUT orgs/WebFirstLanguage/actions/permissions -f allowed_actions=all -f enabled_repositories=all
gh api -X PUT repos/WebFirstLanguage/wfl/actions/permissions -F enabled=true -f allowed_actions=all

Option C — if the tightened allowlist is intentional supply-chain hardening and should stay as-is, then the repo has to stop using non-allowlisted actions: replace dtolnay/rust-toolchain@stable with an inline rustup toolchain install step (24 call sites across 5 workflows), Swatinem/rust-cache@v2 with actions/cache@v4, and stefanzweifel/git-auto-commit-action@v5 with inline git commit/git push. That is a real refactor with Windows-runner implications in nightly.yml, and it should be a deliberate decision rather than an outage remedy. Option A now, Option C later, is the sensible ordering.

Verifying the fix

gh workflow run nightly.yml -R WebFirstLanguage/wfl --ref main
gh run list -R WebFirstLanguage/wfl --workflow nightly.yml --limit 1

A run that reaches queued/in_progress with jobs attached (rather than startup_failure with zero jobs) confirms it.

Deliberately not auto-fixed

Widening an Actions allowlist is a security-policy change, not a CI-mechanics change, so this pass reports it rather than applying it — an automated maintenance run should not quietly re-open a supply-chain gate that a human may have closed on purpose. If it was closed on purpose, Option C is the path and this issue can track it.

Suggested labels: ci, bug, P0.

Posted by the WFL repo warden (automated triage pass).

[logbie]

Resolved

Root cause confirmed and fixed. The repo Actions policy was flipped from selected to all, and CI came back immediately.

// GET /repos/WebFirstLanguage/wfl/actions/permissions
{ "enabled": true, "allowed_actions": "all", "sha_pinning_required": false }

Verification

Manual nightly dispatch, run 31795283997, reached in_progress with real jobs attached instead of startup_failure with zero jobs. Both previously-blocked actions resolved and passed:

✓ Run actions/checkout@v4
✓ Install musl toolchain
✓ Install Rust toolchain          ← dtolnay/rust-toolchain@stable
✓ Cache Cargo registry + target   ← Swatinem/rust-cache@v2
✓ Build wfl and wfl-lsp

WFL Config Lint on #696 has since completed success, and CI is running normally. The startup_failure runs themselves could not be re-run (GitHub refuses — no jobs were ever created), so #696 was closed/reopened to emit a fresh pull_request event.

One correction to the report above

The issue states the org policy is identically selected and concludes org-owner rights are required. That is not what happened. A repo cannot loosen beyond its org policy, so if the org were genuinely restricted to those two patterns, the repo-level change to all would have had no effect. It worked, so the org policy was not the binding constraint. The repo-level setting alone was sufficient to cause and to fix the outage.

If the allowlist is re-tightened later

The minimum is 4 patterns, not the 5 suggested above. actions/checkout@v5 is redundant — github_owned_allowed: true already covers every actions/*, which is why the old list looked plausible while blocking all Rust work.

Action	Uses	Covered by	Needs a pattern?
actions/checkout@v4 / @v5	19 / 1	github_owned_allowed	No
actions/setup-python@v4	5	github_owned_allowed	No
actions/upload-artifact@v4	3	github_owned_allowed	No
actions/setup-node@v4	1	github_owned_allowed	No
actions/download-artifact@v4	1	github_owned_allowed	No
anthropics/claude-code-action@v1	2	verified_allowed	No
dtolnay/rust-toolchain@stable	12	—	Yes
Swatinem/rust-cache@v2	8	—	Yes
stefanzweifel/git-auto-commit-action@v5	1	—	Yes
peter-evans/create-pull-request@v8	1	—	Yes

The outage was masking a broken main — #697

The real cost was not the red X's, it was the merge that slipped through uncovered. #694 merged at 10:42 UTC with zero CI (its run was one of the startup_failures) and broke the nightly Windows job:

error: unused import: `wfl::interpreter::value::Value`
  --> tests\filesystem_mode_test.rs:12:5
   = note: `-D unused-imports` implied by `-D warnings`

#694 consolidated the test helpers into tests/common/mod.rs, deleting the top-level get_global(..) -> Value and expect_text(&Value) — the platform-independent uses of Value. The one surviving reference sits inside #[cfg(unix)] mod unix, so the import is live on Unix and dead on Windows. Linux passed; Windows failed.

Fixed in #697, reproduced Red and verified Green on a real Windows host.

Follow-up worth tracking separately

Option C (replacing the three non-allowlisted actions with inline rustup, actions/cache@v4, and inline git commit/push — 21 call sites across 5 workflows) is still the path if supply-chain hardening is wanted later. It is deliberately not bundled into this outage fix.

Also worth considering: ci.yml and wfl-config-lint.yml have no workflow_dispatch trigger, which is why they could not be manually re-verified during this incident. Adding one would make a future startup-failure outage recoverable without pushing commits.

Closing — CI is green and the regression it hid has a fix in review.