macos-15-arm64/20260511.0048 ships broken Homebrew rustup-init — rejects '+stable' and 'metadata' argv

[jotarios]

Description

The macos-15-arm64/20260511.0048 image ships a Homebrew rustup at /opt/homebrew/bin/rustup (1.29.0) whose bundled rustup-init binary rejects standard argv that the rustup CLI passes to it internally. Workflows that depend on rustup component add, cargo metadata, or any command that triggers rustup's internal download path fail with Error: error: unexpected argument '<word>' found followed by Usage: rustup-init[EXE] [OPTIONS].

The same workflow file on the older macos-15-arm64/20260427.0018 image passes cleanly — confirmed across 5 independent runs.

Repro

Any workflow on macos-latest that triggers an internal rustup-init invocation. Two reproducible paths:

Path A — PyO3/maturin-action@v1: calls rustup component add llvm-tools-preview during target setup. On 20260511.0048 this fails immediately:

[command]/opt/homebrew/bin/rustup component add llvm-tools-preview
info: downloading component llvm-tools
Error: error: error: unexpected argument '+stable' found

Usage: rustup-init[EXE] [OPTIONS]

Path B — @napi-rs/cli: shells out to cargo metadata to read Cargo.toml. On 20260511.0048 this fails with:

Could not parse the Cargo.toml: Error: Command failed: cargo metadata --format-version 1 --manifest-path "..."
error: error: unexpected argument 'metadata' found

The rustup-init binary appears to be interpreting argv that the outer rustup (or cargo shim) is forwarding, and not recognizing standard subcommands or +toolchain syntax.

Evidence

Five data points across one repo (same workflow file, identical commit), all consistent:

Date (UTC)	Run	Image SHA	Result
2026-05-14 03:29	jotarios/chasquimq PR #128 first push	20260511.0048	py-ci x86_64-apple-darwin → +stable failure
2026-05-14 04:05	jotarios/chasquimq PR #128 rerun	20260427.0018	all macOS jobs pass
2026-05-14 04:53	jotarios/chasquimq main commit e67aef0	20260511.0048	py-ci aarch64-apple-darwin (+stable) + node-ci x86_64-apple-darwin (metadata) both fail
2026-05-14 05:03	rerun #1, py-ci aarch64-apple-darwin	20260511.0048	fail (+stable) again
2026-05-14 05:06	rerun #2, py-ci aarch64-apple-darwin	20260427.0018	pass

3 failures on 20260511.0048. 2 passes on 20260427.0018. Zero counter-examples.

Both +stable (maturin-action path) and metadata (napi-rs path) symptoms only appear on 20260511.0048.

Public job URLs

• Failing py-ci on 20260511.0048: https://github.com/jotarios/chasquimq/actions/runs/25842458882/job/75931291550
• Failing node-ci on 20260511.0048: https://github.com/jotarios/chasquimq/actions/runs/25842458851/job/75930434241
• Passing py-ci on 20260427.0018: https://github.com/jotarios/chasquimq/actions/runs/25842458882/job/75931538061
• Passing node-ci on 20260427.0018: https://github.com/jotarios/chasquimq/actions/runs/25842458851/job/75931293285

Symptom in job logs

##[group]Install Rust target
Installing Rust toolchain stable
[command]/opt/homebrew/bin/rustup update --no-self-update stable
info: syncing channel updates for stable-aarch64-apple-darwin
  stable-aarch64-apple-darwin unchanged - rustc 1.95.0 (59807616e 2026-04-14)
info: self-update is disabled for this build of rustup
info: any updates to rustup will need to be fetched with your system package manager
[command]/opt/homebrew/bin/rustup override set stable
info: override toolchain for /Users/runner/work/chasquimq/chasquimq set to stable-aarch64-apple-darwin
[command]/opt/homebrew/bin/rustup component add llvm-tools-preview
info: downloading component llvm-tools
Error: error: error: unexpected argument '+stable' found

The info: self-update is disabled for this build of rustup line is consistent with all Homebrew-installed rustup binaries — so the issue is specifically in the rustup-init bundled with the Homebrew rustup formula on this image release.

Related

#13985 (dup of #13965) tracks a different Homebrew regression on the same image release window (brew update && brew update lock-file race on 20260427.0018+). The rustup-init issue is plausibly the same upstream Homebrew breakage, different downstream symptom.

Impact

Any workflow on macos-latest (or explicit macos-15-arm64) that uses PyO3/maturin-action, @napi-rs/cli, or any path that internally triggers rustup component add / cargo metadata will fail with ~50% probability per job, depending on which runner image the scheduler assigns. Reruns can clear it but are not reliable for release-publish workflows where multiple macOS wheels must succeed simultaneously.

Tested workarounds (none recommended for in-PR fixes)

On jotarios/chasquimq PR #128 we tried four in-PR workarounds — none resolved it cleanly:

1. brew uninstall rustup-init rustup + reinstall from https://sh.rustup.rs upstream installer
2. Same plus rm -rf ~/.rustup ~/.cargo to clear leftover state
3. Same plus sudo ln -sf ~/.cargo/bin/rustup /opt/homebrew/bin/rustup so absolute-path callers find the upstream binary

Each iteration shifted the failure mode in confusing ways because some matrix entries hit 20260511.0048 while others hit 20260427.0018 — patterns that looked like one workaround "made things worse" were actually image-lottery noise. Eventually reverted everything and reran until both jobs landed on the older image.

Suggested next steps

• Confirm whether the Homebrew rustup formula installed in 20260511.0048 differs from 20260427.0018 (formula version or built-from-source binary).
• If it's the same formula version, this may be an interaction with another image change (e.g., Homebrew cellar state, PATH ordering) that affects how rustup-init parses argv.
• A targeted rollback of just the Homebrew rustup formula to whatever shipped in 20260427.0018 should be a safe and minimal fix.

[v-sergei-pyshnoi]

@jotarios Hi! Thanks for detailed report. Can you please confirm that issue still persist? I have tried to fork provided repo with broken workflows and now it seems to be working on latest macos image 20260511.0048.1 (I just made few adjustment to exclude ubuntu and windows from matrix).

Node CI
Python CI

[NyaomiDEV]

Can reproduce on 20260512.0067.

https://github.com/NyaomiDEV/Ampersand/actions/runs/25858481653/job/75982197428

[jotarios]

Hi @v-sergei-pyshnoi — thanks for taking the time to fork and re-run.

We can still reproduce on macos-15-arm64/20260511.0048.1, the same image identifier your forked runs reported. We also caught a clean side-by-side in a single workflow run on PR #130 today (~2h after your green run), where two attempts of the same job drew different images and produced different outcomes:

Attempt	Job	Image drawn	Outcome
1	Build aarch64-apple-darwin (75998407143)	macos-15-arm64/20260511.0048.1	❌ failed
2 (retry)	Build aarch64-apple-darwin (75999176724)	macos-15-arm64/20260427.0018.1	✅ passed

Same code, same workflow run, only the image SHA differs. Image identifiers are read from the Runner Image group in Set up job (the runner-agent's self-reported Image: / Version: lines).

Failure mode on .0048.1 is the original symptom from the issue (no workaround code in this PR, clean branch):

Type Error: Could not parse the Cargo.toml: Error: Command failed: cargo metadata --format-version 1 ...
error: unexpected argument 'metadata' found
Usage: rustup-init[EXE] [OPTIONS]

Notably this fails after dtolnay/rust-toolchain@stable successfully installs upstream rustup — /opt/homebrew/bin/cargo (Homebrew's broken rustup-init shim) still shadows ~/.cargo/bin/cargo on PATH when @napi-rs/cli shells out to cargo metadata. So upstream-rustup-installed is not enough; the broken Homebrew binaries need to be removed from PATH (or uninstalled) for the build to work.

Two things that would help us close the loop on your side:

1. Whether 20260511.0048.1 is a single Packer-baked artifact or whether the .1 revision covers multiple builds in the rollout pool. A single bad host would explain both your green run and our red runs landing on the same identifier.
2. Whether Homebrew's broken rustup/rustup-init is baked into the image at provisioning time, or installed lazily on first brew invocation (and then cached in subsequent steps on the same host). If it's lazy, the trigger order in the workflow matters and may explain the divergence.

Happy to run any diagnostic step you'd like on our side — e.g. logging which -a rustup cargo and brew list --versions rustup rustup-init at the top of the failing job before dtolnay/rust-toolchain@stable runs.

cc @NyaomiDEV — your 20260512.0067 repro is a useful third data point in the same direction.

[montyc1999]

If you are using rust-cache, try adding cache-bin: 'false' as a workaround: Swatinem/rust-cache#341